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

On Mon, Mar 29, 2010 at 12:48 AM, Lester Caine <[email protected]> wrote:
> 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' ;) )

The database client/library either Windows dblib and Native SQL Client
or FreeTDS returns a blank string for unnamed columns. This is the
default client behavior. I cannot MAKE a PHP associative array contain
2 keys of a blank string with 2 different values, it's just not
possible.

While we're SHOULDing all over ourselves... the programmer SHOULD set
the name of the column in the select statement if they want to
reference it by key.

ANSI SQL 92 defines no standard for unnamed column naming it's
"implementation-dependent". If you have a standard, file it as a RFC
or bug.
>
>>> 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!

With the spatial database processing I am doing on millions of rows
rendering them to PDF, another layer of slowness just isn't
acceptable. My apps also process many transactions per second.

http://tonylandis.com/perfomance/php-adodb-pdo-mysql-database-apc-benchmark/

Unless I'm missing something, this performance just won't work for me.

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

I don't need it. If you do, file an RFC for how you think it would best be done.

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

Cross database compatibility is nice. However, I am (un)fortunate
enough to be tied to a particular DBMS ;)

>
> --
> 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
>
> --
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>