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

Matteo Beccati wrote:
> Lester,
>
>> 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 :(
>
> Once again you're comparing apples to oranges. ADOdb and PDO have two
> very different purposes. I'm pretty sure it was said a number of times.

Matteo - YOU are missing the point.

I am not TRYING to compare ADOdb with PDO, but rather pointing out that PDO 
still needs a further layer ON TOP which ADOdb provides. TODAY I have a working 
setup that can easily be switched between most databases without any problems. 
PDO still has a long way to go to add many of those databases to even the lowest 
level of abstraction?

Projects are today switching to PDO because they think it IS feature complete, 
and THEN writing replacements for ADOdb to fit on top which do not have anything 
like the capacity to handle the SQL layer problem. Projects are then actually 
LOSING access to the very databases that they think they are expanding into. 
Having ported their MySQL project to PDO, then trying to get it to work on 
Postgresql they find they have to 'patch' all of the SQL, following which it 
still will not work on SQLite.

My method of testing pdo_firebird is quite simple. I switch between the Firebird 
driver and pdo in ADOdb. This switch SHOULD be transparent on the whole, but a 
number of the 'features' documented on the pdo wiki todo page prevent it being 
usable in a production environment. So you say 'fix the pdo driver', but it is 
fundamental elements of PDO that are causing the problem. It is 'abstracting' 
the data to a layer where the schema's from different databases simply can't be 
transparently used. One HAS to address the SQL level to create projects that can 
transparently map between databases, and PDO is actually preventing that at 
present. Fundamentally, BLOB's have to be able to be used either as raw data or 
as text fields and that is what is currently not practical and preventing 
firebird and oracle from accessing the data from a MySQL pdo setup.

You can not just look at data abstraction in isolation, the whole picture needs 
to be addressed. The question was asked 'why re-invent the wheel' and that is 
exactly what I am saying. We HAVE a fully functional solution that MAY need some 
work at the lower level, but which addresses the whole problem rather than 
missing the point at the lower level. The criticism of ADOdb is that it is too 
'heavy' and 'slow', but PDO is not actually addressing either of those problems. 
They will exist what ever top layer you put on PDO, so why not address the 
problem by simply taking what IS working and work to speed that up?

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