Larry Garfield wrote:
As a case in point, I recently tried to implement a PDO layer for Drupal as an
alternative to the mysql_* implementation. Drupal currently implements its
own prepared statements in user-space, using a printf()-like syntax and
preg_replace_callback(). When I replaced that with PDO's own prepared
statements, I found performance was about a wash[3]. On the other hand we do
get type-safe prepared statements and simpler code, so we're planning to move
to PDO in Drupal 7 at this point.
[3] http://drupal.org/node/134580
That nicely summaries some of the aspects of moving to PDO from the user side.
You are thinking that you will have to support PHP4 and non-PDO drivers until
2012 :)
The main thing I see there is 'raw' SQL. Loading the variables directly into
the script, rather than simply binding them as params. I have yet to work out
a way of converting some of my dynamically generated SQL into a format that
will work with PDO - on any database. I've only ever used ADOdb and that
handles ALL of the parameterizing of things transparently.
The other problem of cause is length of table and field names and reserved
words. Adding Oracle and MsSQL to the mix, working with raw upper case table
and field names and 31 character name limit introduces a few extra things to
consider over and above just adding PDO to Drupal ;)
NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.
My knowledge and experience with Firebird is nil, so I cannot say anything
useful for that.
The only point I was making here is the one you have covered - we need to
support PHP4 for some time yet - which ever database you are using :(
The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?
Are you talking about Firebird-specific features, or all non-SQL-standard
queries? As far as I know PDO allows arbitrary strings as queries so
SQL-esque database-specific stuff should still work. Wez, is that not the
case?
There are other interfaces other than just the 'SQL' one for talking to but
then the database industry are working from the other end to come in line with
the standards. Perhaps another one for 2012.
I make no claim of being a PDO expert either, and my database experience is
98% MySQL, but the above is my experience and reading so far with it. PDO's
main selling points are 1) A fully OO API and 2) A common API for all
databases. By nature, it does result in "lowest common denominator" issues
as well, including potentially performance. If you're aiming for
cross-database compatibility, I'd recommend it over rolling your own. If you
can guarantee that you'll only need <insert some database here>, then the
specific driver may be a better option in some cases. YMMV and so forth.
TODAY - I think that is right.
I'm not as negative about PDO as people seem to think! It is just that TODAY
there is a packaged working solution to MY problem, which many other people
are using as well so there is no need to spend time 'rolling your own' version
of PDO that mirrors those facilities?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
