# Status PDO drivers in general - Thread: https://externals.io/message/45574 - Original archive: https://news-web.php.net/php.internals/45574 - Started by Lester Caine on 2009-09-15T07:04:34+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #45574 — Lester Caine — 2009-09-15T07:04:34+00:00 URL: https://externals.io/message/45574#45574 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 --- ## #45575 — Vesselin Kenashkov — 2009-09-15T09:04:53+00:00 URL: https://externals.io/message/45574#45575 · In reply to: #45574 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 --- ## #45588 — Lukas Kahwe Smith — 2009-09-17T14:14:37+00:00 URL: https://externals.io/message/45574#45588 · In reply to: #45574 > 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 --- ## #45596 — Lester Caine — 2009-09-17T20:51:53+00:00 URL: https://externals.io/message/45574#45596 · In reply to: #45588 Lukas Kahwe Smith wrote: > 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. I think unfortunately this identifies the current situation :( I was prepared to spend time on the firebird driver, but on closer investigation it would seem that there are some core problems with things like clob/blob that means - with my limited digging - that they can't be used as simple string fields? This then causes problems porting new PDO code to work with firebird ( and oracle ) as well as MySQl and PostgreSQL. At the end of the day removing the PDO port and restoring ADOdb only took a few hours and is working nicely .... but I AM prepared to spend a little more time on PDO if someone who understands how it works internally can point me in the right direction! -- 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