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

Stanley Sufficool wrote:
> On Sat, Mar 27, 2010 at 12:04 AM, Lester Caine<[email protected]>  wrote:
>> Stanley Sufficool wrote:
>>>
>>> 4. Removed automagic compute column naming (which was clobbering library
>>> memory). Just return what the server returns including empty strings.
>>> The user will need to alias in their sql query as "select 1+1 as
>>> oneplusone" instead of just "select 1+1" magically returning
>>> array('compute1'=>'2').
>>>
>>> Question: Who if anyone relies on this behavior? I don't see other
>>> drivers doing this.
>>
>> That is a little more fundamental question ;)
>> Since PDO is currently scoped only to abstract the data, then anything
>> related to changes to the SQL should not be happening. So in theory if you
>> switch the driver a simple SQL query should still work? There are many
>> reasons why it will not work but that is not for PDO to address! So there
>> should be nothing 'automagical' in any of the drivers unless it produces
>> results that are SQL standard compliant across all drivers?
>
> Yes, I don't think an abstraction layer should add anything to the
> returned data unless it is done uniformly across all drivers.
>
> More specifically, My question was, should a fetch() on "select 1+1,
> 'sometext' " return:
> array(0=>2, 'compute1'=>2, 1=>'sometext', 'compute2'=>'sometext')
> or
> array(0=>2, ''=>'sometext', 1=>'sometext').
>
> My preference being the latter since it is my own fault for not being
> specific in my SQL column naming and that there is not real way to
> ensure these columns are renamed consistently across all drivers.

Other drivers will still give something different, but there should only be as 
many entries in the array as columns in the query ....

>> My own stand point is that PDO is still not user ready until it provides a
>> little more REAL cross database compatibility, so something like this is not
>> acceptable and must be addressed in the SQL initially provided.
>
> PDO is at least a step in the right direction. We can add another
> SQLParser layer on top of or in PDOStatement to provide complete SQL
> abstraction for non-relational data (CSV, BerkDB, dbase, GDAL, etc...)
> . However, this is more than likely re-inventing a lot of ODBC work
> that has already been done.
>
> Goal #1, get all the PDO basic functionality implemented across as
> many drivers as possible and stabilize. Goal #2, extend PDO to allow
> each driver implementation to support specific functionality of the
> DBMS so that all of the database extension maintainers (mysql, pgsql,
> mssql, oci8, sqlite, etc...)  can get on board with PDO without losing
> functionality.
>
> PDO needs to bring more people to the party. I'm starting to look
> longingly at Java and JDBC.
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 :(

> So more comments needed, or can we commit this patch? Since this
> extension is marked experimental, I think the behavior change should
> be acceptable.
Anything that fills in holes should be committed?

-- 
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