Re: Which Database Abstraction Layer ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On 09/11/2004 11:11 PM, Hans Lellelid wrote:
/abstract/ stuff. For example, ADOdb would completely fail to be portable accross databases where the case of the column names in result array changes (e.g. postgres always returns lowercase col names, Oracle always uppercase, MySQL returns mixed case, SQLite is configurable). This is one example of why some layers (like PEAR::[M]DB) may be slower.

This is incorrect. You can configure the case of the column names in ADOdb. See http://phplens.com/adodb/reference.constants.adodb_assoc_case.html
>
Sorry about that. I certainly don't want to spread disinformation (!) Is this true for all the drivers ... ? E.g. I looked at the postgres64 driver and saw no case-changing code in the MoveNext() method; I didn't look at the other drivers after that, though.

You are right Hans, there is no completely portable solution for returning result set rows as associative arrays. Even if you waste time, mapping the case of column names, there is also a problem that you did not mention that is that there are some databases than mangle column names larger than a certain limit.


For this there is no solution. Even you bother to waste even more time parsing the original query and are aware of the exact column name limit, there is always the chance that two distinct columns are returned with the same name because they differ only in characters after the limit.

This is why I never accepted suggestions to add a function to retrieve result sets as associative arrays to Metabase despite many requests.

I am not sure about the column name length limits of all databases, but if I am not mistaken Oracle's is limit is low. This is also part of the reason why I decided to not bother to implement ROWNUM based tricks in Metabase Oracle driver to implement a row range limiting based on parsing the query like Thomas Cox implemented for PEAR-DB and John Lim copied for ADO-DB.

Actually the advice to not play with tricks of doubtful feasibility came from PHP Oracle gure Thies Arntzen. Chances are that soon or later an users of your database abstraction package will find an hairy query that will break those tricks and will be mad and stuck with feature that does not work.


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux