Re: cvs: pear /DB/DB dbase.php fbsql.php ibase.php ifx.php msql.php mssql.php mysql.php mysql4.php oci8.php odbc.php pgsql.php sqlite.php sybase.php

From: Date: Sat, 03 Jan 2004 08:19:23 +0000
Subject: Re: cvs: pear /DB/DB dbase.php fbsql.php ibase.php ifx.php msql.php mssql.php mysql.php mysql4.php oci8.php odbc.php pgsql.php sqlite.php sybase.php
References: 1 2 3 4  Groups: php.pear.cvs php.pear.qa 
Request: Send a blank email to pear-qa+get-329@lists.php.net to get a copy of this message
Hi Alan: On Sat, Jan 03, 2004 at 01:26:28PM +0800, Alan Knowles wrote: > Daniel Convissor wrote: > If you need to support oracle then using lc keys looks like the only > option. - but otherwise it is a bit of a annoyance to other drivers if > you never use oracle, but need other features of portability.. By the way, oracle isn't the only DB to change the cases of column names, so there needs to be a consistent way to handle these differences: UPPER InterBase Oracle LOWER PostgreSQL PRESERVED MSSQL MySQL Sybase FYI while we're "going there," here's what the various db's do with padding: YES InterBase MSSQL Oracle PostgreSQL Sybase NO MySQL > If it was being done fresh today.. the best solution would be > $option['portability'] = > DB_PORTABILITY_LOWERCASE + //1 > DB_PORTABILITY_DELETE_FIX + //2 > DB_PORTABILITY_NUMROWS + //4 > > this could be added as a condition in setOption: > if ($option== 'optimize') { > $this->options['portability'] = ($value='portability') ? 7 : 0; > } Yes, that's nice! Perhaps Lukas is right and we could do something like this without too much overhead or compatibility breakage involved. I'm tired now. I'll think more about this later. > I would suggest > a) making portibility a depreciated option Do you envision some other option taking its place in order to provide portability? I mean, the primary point -- at least for me -- of using DB is the ability to change DBMS's without having to change my application. Heck, if I didn't care about portability, I wouldn't even bother with the overhead of DB and would go with the direct db specific functions. > b) modify the tableInfo returns to do the lowercasing as well. Hmm... Why? Is table info used for anything beside just knowing the structure of a given table? If so, then what's the value of having them lowercased? > >The point of quote() is to make a variable safe for insertion into a > >query. > > Not acording to the docs "DB_Common::quote() -- quotes a string" Aw, come on now... don't forget the description :) "Quotes a string database-dependent, so it can be safely used in a query." Perhaps we have different interpretations of what that means? > One of the main failings of using PHP types to determine quoting is > quoting should be dependant on the field type in the databases (not the > PHP type) True. But in coding your application, you ensure the PHP type is what the column type is supposed to be, which is what several drivers (most importantly, the MySQL driver) already did. > Options > b) Fix magic & add method simpleQuote > + at least behaviour is consistant. > + reasonably BC > - method name / documentation not perfect.. > > b) looks like the best option here. Yes, of the options presented. Two "of course..." statements, though. First, thought the docs aren't perfect now, that will be rectified. Second, there's the option of continuing the way things are now. All that aside, what do you envision a new simpleQuote method doing? Good nigt, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

« previous php.pear.qa (#329) next »