Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.125 cause and error)
Message-ID: <4AAF3C82.7000500@lsces.co.uk>
Date: Tue, 15 Sep 2009 08:04:34 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.23) Gecko/20090908 Fedora/1.1.18-1.fc11 pango-text SeaMonkey/1.1.18
MIME-Version: 1.0
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Status PDO drivers in general
From: lester@lsces.co.uk (Lester Caine)

Having now established that while functional, the firebird PDO driver is 
simply not usable in real life applications, I've been reviewing the PDO 
bug list initially to see if the problems I've encountered are already 
listed.

First problem is simply identifying which bugs relate to which driver, 
or the core package. But the main problem was simply trying to debug 
things since every problem simply returned a white screen. Adding 
another layer of try/catch got things a little under control, but while 
perfectly valid SQL on firebird prepares and executes, fetching the 
results seems to be a little problematic.

I think I am seeing the same problem with other drivers, so I don't 
think this is simply a problem with firebird. pgsql, mssql, oci, odbc 
and even mysql have some of the same bugs listed that I've been hitting 
with firebird, so the question has to be exactly where a fault is?

The MAIN thing for which I have been asking for help relates to the use 
of blob fields as large 'TEXT' fields, and oci is reporting the same bug 
with the clob fields. The 'application' I have been trying to debug uses 
a large text field in almost every table, and in the pre PDO environment 
this mapped to a 'BLOB SUB_TYPE TEXT' in firebird(interbase) and CLOB in 
oracle. Any attempt to use that in PDO simply fails, but I THINK this is 
because I need to use a different 'bind' method for that field? How is 
this then compatible cross database? It's bad enough trying to sort out 
the mess of SQL without having to fix differences in handling data :(

Having given a good day or so to working through the PDO version, by 
which time I had got the installer working, and even an import clipped 
to 32000 characters for the large text fields ( using VARCHAR rather 
than BLOB fields ) I was hitting problems with UNION and other more 
complex SQL which required breaking down and doing some of the work in 
PHP to get the required results.

Not making any real progress and not getting any replies to questions 
here or on the general list I simply pulled the plug on the PDO 'class' 
and replaced it with my well proven ADOdb 'class'. Within 8 hours over 
Sunday night and Monday morning I had the core fully functional, and a 
couple of hours yesterday restored most of the 'extras'. The main thing 
being that the ADOdb error handling was identifying problems for which 
PDO had just been a white screen!

I have no doubt that PDO works fine for many people, but since the 
limited target that it had was for data abstraction IS this actually 
achieved currently? Which drivers ARE fully functional, and what 
outstanding bugs remain on each?

What is really needed is a wrapper like ADOdb that gets things under 
control, rather than every project creating their own implementation. 
This is the nice thing about ADOdb - it may be 'heavy' but it 
'abstracts' the data in a way PDO seems unable to do.

(SQL abstraction is simply another matter)

-- 
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