Bug #73650 [Com]: why lose sql-results their type in PHP?
Edit report at https://bugs.php.net/bug.php?id=73650&edit=1
ID: 73650
Comment by: spam2 at rhsoft dot net
Reported by: spam2 at rhsoft dot net
Summary: why lose sql-results their type in PHP?
Status: Open
Type: Bug
Package: *Database Functions
PHP Version: 7.0.14
Block user comment: N
Private report: N
New Comment:
anyways, at that point in time i would be happy if only run-tests.php would respect the environment
and not load random configurations not matching the build which is running the test
and the reason for run it directly instead of "make test" is that "make test"
has nothing better to do then copy /etc/php.ini instead enforcing a empty default config
https://bugs.php.net/bug.php?id=73609
Previous Comments:
------------------------------------------------------------------------
[2016-12-08 19:37:47] spam2 at rhsoft dot net
> PHP's int is only signed 32 bits int under 32 bit architecture
show me the machines running in 2016 PHP70/PHP71 under a 32 bit architecture *and* then using
declare(strict_types=1); - frankly linux distributions are stopping to build any 32bit stuff at all
- there is no RHEL7 even while it ships PHP5.4
how many decades should we accept a doezen potential 32 bit machines stop envolving things? when i
develop in strict mode and store a integer to mysql i excpect to get that integer back and not a
random string which i have to cast manually or the whole strict_types is pointless because it only
leads to fatal errors for no good reasons or you have to use (int) everywhere when something might
have came from a database which makes any benefit of typing pointless
------------------------------------------------------------------------
[2016-12-08 19:26:18] cmb@php.net
If there is any chance, that an integer retrieved from a database won't fit into a PHP int, the
proper way to deal with this would be something like:
<?php
if ($row['id'] >= PHP_INT_MIN && $row['id'] <= PHP_INT_MAX) {
foo((int) $row['id']);
} else {
// uhm, we can't cast $row['id'] to int â¦
}
------------------------------------------------------------------------
[2016-12-08 19:06:04] spam2 at rhsoft dot net
> Integers in database may not match PHP internal
> date types. e.g. PHP's int is only signed 32 bits
> int under 32 bit architecture
but how is that different to $row['id'] = (int)$row['id'] which you now must do
manually becaus eotherwise sooner or later a function in a class with declare(strict_types=1); will
end in a fatal error?
__________________________
inlcude('functions.php');
$row = mysqli_fetch_result($result);
foo($row['id']);
is a fatal error currently without foo((int)$row['id'])
__________________________
functions.php:
<?php declare(strict_types=1);
function foo(int $id)
(
)
?>
------------------------------------------------------------------------
[2016-12-05 01:26:28] yohgaki@php.net
Not only DBMS, but also almost all inputs are "string". Converting types to appropriate
one could be convenient, so I wrote a RFC for it.
https://wiki.php.net/rfc/introduce-type-affinity
The RFC isn't intended to use with database inputs, but this kind of feature may be useful if
feature supports some kind of "schema".
------------------------------------------------------------------------
[2016-12-05 01:20:38] yohgaki@php.net
Automatic type conversions do harm more than good.
Integers in database may not match PHP internal date types. e.g. PHP's int is only signed 32
bits int under 32 bit architecture. Database's INT8 could unsigned with MySQL/etc.
SQLite's type is pseudo type and could be any text even when columns are defined as int/etc.
Converting other system's types to PHP type should not be automatic, but manual. We
shouldn't do the same mistake done in JSON again. I'm against to have broken automatic
type conversions.
That said, I don't oppose to develop workable type conversion framework.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=73650
--
Edit this bug report at https://bugs.php.net/bug.php?id=73650&edit=1
Thread (10 messages)