ID: 38334 Updated by: [EMAIL PROTECTED] Reported By: maximkh at yahoo dot com Status: Open -Bug Type: PDO related +Bug Type: Feature/Change Request Operating System: Linux/Windows PHP Version: 5.1.4 New Comment:
Since this is the intended behavior, there is no bug and your report should be classified as "feature request". >If not, I have to go back and spend a ton of time writing > wrappers for PDO that will emulate what should have been > proper behavior. You also can spend some time and cook a patch, that adds the functionality you want, we would gladly review it. Previous Comments: ------------------------------------------------------------------------ [2006-08-14 13:55:56] maximkh at yahoo dot com Ok listen, until someone actually starts reading Feature/Change Requests, this is a PDO related issue. It's already been nearly 2 weeks, and I have yet to hear anything constructive from anyone. All I want is for someone to spend 5 minutes and tell me if there is even a chance it will be fixed in the next release. If so, great, I'll shut up and won't bother you. If not, I have to go back and spend a ton of time writing wrappers for PDO that will emulate what should have been proper behavior. ------------------------------------------------------------------------ [2006-08-13 15:58:43] maximkh at yahoo dot com Not exactly, it WAS typeless in version 2. As of version 3, it has well defined types as explained in the documentation: http://www.sqlite.org/datatype3.html If I was to store the number 18446744073709551615, SQLite v3 would store it as an 8-byte integer, but since PHP forces a conversion to string, it would take up 20 bytes. I'm sure you can see the problem, especially when dealing with certain scientific applications which is what I'm trying to write and use SQLite with. Considering that there is a perfect match between SQLite and PHP data-types, there is really no reason not to implement them... NULL -> null INTEGER -> integer REAL -> float TEXT -> string BLOB -> binary string After taking a look through the actual PDO_SQLITE code, this kind of change would take half an hour to implement, so I see no real argument against it. ------------------------------------------------------------------------ [2006-08-13 14:54:19] [EMAIL PROTECTED] SQLite by its nature is a typeless database, adding virtual type support to it, is by its nature a feature. ------------------------------------------------------------------------ [2006-08-11 13:41:58] maximkh at yahoo dot com . ------------------------------------------------------------------------ [2006-08-07 20:54:02] maximkh at yahoo dot com Looks like it's back in "Feature/Change Request" section... Fine, though I don't think supporting proper data-types is an extra "feature". Ok moving on, I figured out a way to get passed both problems, but it basically eliminates all advantages of PDO, and actually makes things a lot worse. As stated above, if you manually escape the data and don't use variable binding, the data is inserted as proper data types. When performing a select on that data, PDO_SQLITE will always convert it into a string, however, PDOStatement::getColumnMeta does return the correct native_type field (null, double, string, or integer). This means that if you want data types to be preserved when selecting, you need to loop over every row using PDOStatement::fetch(), use the getColumnMeta for every column in that row, do the conversion, and store the result in a PHP array (2-dimensional). As you can imagine, that is one slow process. That sounds like an absolutely terrible solution to me, which is why I again ask for at least some sort of a response from one of the developers on this issue (not that I don't enjoy talking to myself). ------------------------------------------------------------------------ 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 http://bugs.php.net/38334 -- Edit this bug report at http://bugs.php.net/?id=38334&edit=1
