Re: [PDO] Fwd: Bug #50755 [Opn]: PDO DBLIB Fails with OOM

Stanley Sufficool wrote:
>> Other drivers will still give something different, but there should only be
>> as many entries in the array as columns in the query ....
>
> There are 2 entries in the array for each column with fetch(). One
> numeric (ordinal) and one associative (column name). Since I do not
> formulate a name for non-aliased computed columns, 2 columns have an
> associative index of blank string "" and therefore, only the last
> entry is registered under the blank string. You would get the same
> from thecurrent implementation if you tried "select 1+1, 'sometext' as
> compute1" and a fetch(PDO::FETCH_ASSOC) would return
> array('compute1'=>'sometext') but a fetch(PDO::FETCH_NUM) would return
> both columns.

This is still 'database' dependent. Column naming is a function of the database 
client normally. Firebird would provide unique names ( and they vary depending 
on version of Firebird but that is another matter ) for each column. Converting 
those to numbers is done by the driver. Oracle I think does the same? Getting an 
SQL query to return the same names for columns needs the 'as xx' properly 
defined? ( Yes the default setting returns both sets, but they SHOULD still be 
'the same number as in the query' rather than 'maybe the same number' ;) )

>> ADOdb has always provided a clean abstraction for me and will work the same
>> with PDO drivers as all of the generic drivers, so - yes - why reinvent the
>> wheel. The ADOdb extension provides a much more flexible soultion than the
>> current PDO offering, and addresses many of the 'complaints' that ADOdb is
>> too slow. It handles generic drivers quicker than their PDO alternatives so
>> apparently ignoring the SQL aspects is detrimental to the final
>> implementation :(
>
> Back to Goal #1.... ADODB can be looked at as a higher level
> abstraction at Goal #2. We need basic Driver abstraction first.

BUT we need a lower level abstraction that actually works. PDO does not yet 
provide a lower level that abstracts UNLESS you also write the higher level to 
fix the mistakes PDO currently makes. We still need to agree how to get PDO to 
drop the stream connection for BLOB fields - selectively - where databases use 
BLOB/CLOB in the same way as TEXT. It is this problem that is preventing my 
doing any further work on PDO as I can't mirror the data returned by MySQL in 
the project that has now moved to PDO as their base in my Firebird setup. It was 
a lot easier simply to drop ADOdb in and restore functionality since I needed a 
working codebase!

Some of the other items on the todo list for PDO are simply not fixable given 
the current structure of PDO - such as cross database transactions. So either 
PDO will only ever be a 'restrict everything to this sub set of functions' or we 
need to fill in the holes to allow the PDO drivers even to be considered as 
replacing the generic drivers in the future?

In the meantime we still need to be able to build cross database projects.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php