Edit report at https://bugs.php.net/bug.php?id=63958&edit=1
ID: 63958 Updated by: u...@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] johan...@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
