Following on ....
Lukas Kahwe Smith wrote:
Lester Caine wrote:
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.
I have no clue what type of dynamically generated SQL you are talking
about. Are you talking about being able to dynamically stick identifiers
into placeholders? This is simply not possible if you are using native
prepared statements. If you emulate them, yes you can, but then you can
might as well use sprintf() with quote() (maybe with a wrapper).
OK this is a key difference between MySQL and other databases - at least
looking at the raw drivers. Firebird ( and PostgreSQL ) can use parameters to
handle the transfer of values to the query.
From pg_query_params manual - "The primary advantage of pg_query_params()
over pg_query() is that parameter values may be separated from the query
string, thus avoiding the need for tedious and error-prone quoting and escaping."
Most projects I work with, build an array of values to be processed, and then
just create a simple SQL query to pass the array to the database.
PDO does wrap this quite nicely, except that BLOB's can only be passed as raw
content? The ability to just pass a BLOB ID means that you only access that
part of a large blob that you need. And most database engines would benefit
from being able to handle BLOB elements independent of the general fetch.
Rather than duplicating and processing several hundred 'k' text blobs, you
just pass the link to the original?
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 ;)
PDO handles some of those, but as said tons of times before, its not an
abstraction layer, its an API unifier. There are PDO based layers like
Doctrine, that give you all the convinience of ADODB (and more ..). They
do however require that the underlying PDO driver is solid.
At any rate .. why bother with PDO when there are "native" extensions?
The point of PDO was not only end user focused, it was also the idea to
one day make it less effort to add new features to all the RDBMS
extensions (for example unicode .. that being said I keep hearing that
PDO HEAD is totally out of sync). It also makes it a lot easier to add a
new RDBMS extension.
The IDEA is still good. It just needs the core tidying up a little more before
it becomes totally practical.
Now if we stick with maintaining the current non PDO extensions, then
you must realize that we are maintaining a lot of redundant code, which
is based on one of the oldest extensions (ext/mysql). Since we do not
have infinite development resources, it would be for the better of any
of the supported RDBMS if it would get its PDO driver up to the same
level as the old extension. As more and more of our userbase is moving
to PHP5 this hopefully will become more and more interesting.
Having finally got to the point where PHP4 *IS* being end of lifed, then one
of the major stumbling blocks HAS been removed. That is why I *AM* now coming
back to this - after 2 years - and trying to nail down some of the remaining
problems. I have had to be careful even with the Firebird driver to ensure
that only functions available in PHP4 are used in ADOdb, but it will be nice
to be able to say - that version of project X is the last which will support
PHP4!
NOW we can get on and start looking for PHP6 and proper Unicode support -
Firebird can run DIFFERENT character collations in each field something else
that still needs the native driver to handle ;)
--
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
