On Thu, Nov 4, 2010 at 7:44 PM, Richard Lynch <c...@l-i-e.com> wrote: > 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. :-)
FWIW, large objects cannot be used in ORDER BY in MSSQL, and relational integrity is best achieved by having your data in a -relational- database. Think mugshots, digitized signatures, etc. I really do not wish to cycle through a record set to do a pass to delete the images on disk by filename reference and then run another SQL to delete the records. > >> 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. And what ANSI SQL date conversion function would you suggest to outputa consistent string date/time? CAST(date as varchar)? Inconsistent at best across MSSQL, Oracle, PostgreSQL. > >> 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?! Because all data on the wire from TDS is UTF16, including query strings. > > And why is PHP client library using latin1 for data that just isn't > latin1? That's just asking for problems... Theoretically I could ask for UTF8, but then I don't want to have to run utf8_decode/utf8_encode on all query strings, returned data, etc when the other drivers do not return unicode to PHP. > > 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... iconv is implemented in the freetds library outside of PHP. I guess I could copy all of the freetds library code into pdo_dblib to avoid iconv and external dependencies (making it a native driver)? It was a side thought in order to get pdo_dblib working on Windows. > > 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? :-) MSSQL allows per table and per column code pages in recent versions. As far as OpenSource DBMS', I support what my clients run, not what I want them to run. If I had my choice, I would be running PostgreSQL. > >> 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
