Status PDO drivers in general View as Markdown

White screen usually means a segmentation fault - php crashed. I guess the
best option you have is to repeat all these situations when it crashed and
to get a backtrace and post it under the relevant bug or create a new one.
I also had a disappointing experience with PDO. I used before adodb as well
and migrated to pdo and tried to have an app working with both mysql &
oracle but the pdo/oci combination didnt work for me. I hit a CLOB problem
reported already (I just added my comment & trace):
http://bugs.php.net/bug.php?id=44589
Unfortunately if you just walk through the "php 5 bug summary report" you
will see that PDO list is one of the longest (and it always have been). What
we can do is at least report the problems and hope that someone skilled will
fix them (this is by no means a criticism to the php team, don't get it this
way).

Vesselin Kenashkov

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

--

--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com

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?

The list of bugs is long, the number of people looking after them and
their time is small. This is a real problem.
Some things are not easily wrapped without a lot of assumptions and
limitations. PDO only tried to unify the really simple stuff but make
it possible to t least do the complex. However blob/clob handling is a
bit unwiedly in some ways (requiring the bind API and type parameters)
it does make a few things nicer (mainly returning a stream).

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.

However it does make the code necessary to handle RDBMS differences a
lot smaller, thought it of course does not compete with MDB2, Doctrine
or ADOdb.

Anyways it all boils down to having developers care. It mostly works
for MySQL and SQLite I guess. PostgreSQL has seem some love recently.
IBM seems to not care anymore. Oracle certainly doesnt. Microsoft
never did. A really bad situation for such a core technology.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org