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: | Daniel Convissor | 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