Req #63958 [Opn->Wfx]: Fetch provides only strings with MySQL
Edit report at https://bugs.php.net/bug.php?id=63958&edit=1
ID: 63958
Updated by: uw@php.net
Reported by: r dot schneider at artworx dot at
Summary: Fetch provides only strings with MySQL
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: PDO related
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
From MySQL side: won't fix. As Johannes explained, there are two different flavors of the MySQL
protocol: text and binary. If using emulated PS, text protocol is used, thus you get strings. This
is how the server works.
From all I know, PDO spec don't require any alignment here.
Previous Comments:
------------------------------------------------------------------------
[2013-01-14 08:04:42] r dot schneider at artworx dot at
Do you mean the meta data that I can obtain with getColumnMeta? I don't like to use it as it is
experimental.
If you look at this http://stackoverflow.com/questions/5405813/php-selecting-from-mysql-and-receiving-th-data-types?lq=1
you see that I'm not the only one having this issue. But in this post someone argues that PHP
is weak typed. That means that it would be okay that the fetch methods return string values when
using MySQL. I think this behaviour could be noted somewhere. I assume many people expect that the
real data types will be returned.
Can anyone give me an example or a link for a native prepared statment, please? I'm still not
sure what it really means. Thanks.
------------------------------------------------------------------------
[2013-01-13 09:24:22] vincent at lycoops dot be
I don't get why you can't return the true data type. You have the result meta data, so you
can convert those types.
Setting the atrtibute ATTR_EMULATE_PREPARES should not be the only solution (because it does not
only have advantages).
------------------------------------------------------------------------
[2013-01-10 15:47:08] r dot schneider at artworx dot at
What I have seen now: in http://php.net/manual/en/mysqli-result.fetch-object.php
it is stated that the returned values will be of type string.
Maybe this should be stated in fetchObject (and other fetch methods) of PDO as well.
------------------------------------------------------------------------
[2013-01-10 15:41:56] r dot schneider at artworx dot at
What are native prepared statements? Do you mean stored procedures?
Let me ask in another way. How could an object easily gets populated with the correct data types?
/** This class has the same/equivalent
data types as in an corresponding table */
class A {
/** @var int $id */
private $id;
/** @var string $name */
private $name;
/** @var float $size */
private $size;
/** @var DateTime $lastLogin */
private $lastLogin;
}
DateTime might be a bit more sophisticated. But the primitive data types should get the right types.
But this is not possible with fetchObject('A'). All member variables will be strings.
Should fetchObject not be used that way? Should it be used only for fool data classes (classes
without methods)?
Or is this not the php style? Should I 'ignore' primitive data types? What would mean
fetchObject('A') is okay.
Or is it intended that fetchObject is only for 'string classes', or that the call usually
needs some rework?
Wouldn't it be good if we could get the correct data types?
Maybe it is my lack of knowledge. If so then sorry for the ticket. But I never came across anywhere
that told me that MySQL/PDO returns strings only and, because of that, to use it in a certain way.
That's why I suggested to put this into the documentation.
Thank you!
------------------------------------------------------------------------
[2013-01-10 14:57:17] johannes@php.net
How does this make "the proper usage of fetchObject('myClass') not possible"?
The reason is that the MySQL Server sends strings to PHP. PHP doesn't touch it further. If you
use native prepared statments (PDO uses an emulation by default) MySQL switches to a different
protocol and you get more native types (while even that doesn't cover all types properly -
thing MySQL DECIMAL, there is no precise numeric type in PHP for non-integers)
------------------------------------------------------------------------
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=63958
--
Edit this bug report at https://bugs.php.net/bug.php?id=63958&edit=1
Thread (7 messages)