On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote: > On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch <c...@l-i-e.com> wrote: >> On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
I realize as the guy who has to deal with the driver code and what it should do for people not following the advise below, it's probably preaching to the choir, but... Read the below comments this way: Anybody dumb enough to rely on the kind of stuff you are asking about is already in Big Trouble (tm). > I realize that non Zend types would have to be returned as a string > representation. At the risk of repeating myself, even Zend types aren't going to match up -- The devil is in the details. The range for an INT in the DB won't match the range for a Zend INT, for at least some databases, almost for sure. I know 2s complement is 2s complement all over, but there has to be SOME DB out there that has a range +/- 1 compared to Zend INT. > The hangups I am having is with large objects returned > as streams in some drivers (but not dblib) I never really use large objects, as anything that large doesn't belong in the database in the first place... :-) Rule Of Thumb: If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it doesn't belong in the DB. Put it in the custom highly-optimized specialized database engine commonly known as "the file system" where it belongs. :-) > and inconsistent date/time > string representations across drivers depending on server > configuration files (freetds.conf). Ewww... I generally use the DB date format feature to format dates in a consistent manner, rather than rely on whatever random date/time output the DB/driver chooses. > Another BIG issue I am having when using strings with DBLIB is that > they go through iconv, destroying binary values when translated to the > server character set from the assumed latin1 PHP client character set. > SQL Server for some reason allows characters to be stored in a > varchar/text fields even though the character is not defined in the > servers code page, whereas iconv pukes with an error. I'm not an i18n expert, but... Why is iconv being injected at this point?! And why is PHP client library using latin1 for data that just isn't latin1? That's just asking for problems... I would expect any driver to just give me the raw data from the database, in the charset defined by the DB, and not to try to down-sample it to some other charset for me... Though I guess if you've told the PHP client to make it be 'latin1' the best it can do is trash it through iconv and you get what asked for... My only answer to that is to change your code to not ask for 'latin1' in the first place, when the data isn't latin1. Change the PHP client charset to what it ought to be, and get the data you wanted, not some lossy down-sampled useless conversion of the data you wanted. I cannot comment on SQL Server behaviour with respect to the "servers code page" [sic], whatever that is, except to say that MySQL lets you define your charset on a table by table basis, and, I think, in recent versions, even on a field by field basis. OpenSource ftw, perhaps? :-) > It would be a wonderful development to have an RFC on the preferred > string representation of various objects as returned by the driver so > that when using ANSI SQL with PDO you can expect the same > representation across all drivers. I'm all for documenting what SHOULD happen across all drivers, if a) the docs are sensible, and b) it can be implemented in all drivers I suspect that even a) would generate a TON of discussion on this list that would never be resolved, and that b) is simply not possible due to some really brain-dead drivers. But that's just my naive "gut" talking, with no real specific knowledge. ymmv -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
