Lester Caine wrote:
Christopher Jones wrote:
Lester Caine wrote:
I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO
driver you need to also run the native driver simply to provide the
areas NOT covered by PDO. We need a generic framework that addresses
the real problems not one that creates an artificial lowest common
denominator strangle hold :( PDO could evolve into that, but not with
it's current restrictions.
Can you list the current restrictions as you see them?
Actually the very first one has been addressed and has nothing to do
with PDO. Up until recently is was essential to provide backwards
compatibility with PHP4 and all of the projects I currently work with
WOULD still install on PHP4. Although *I* never used it in production,
the continued support meant that there was a large base that insisted on
retaining it. So ADOdb's continued underlying support for PHP4 is useful
and until there are a higher percentage of PHP5 users than PHP4 - PDO
takes second place as it is not available on a large number of hosts?
The next problem builds on the above one. From the PDO manual "PDO does
not provide a database abstraction; it doesn't rewrite SQL or emulate
missing features. You should use a full-blown abstraction layer if you
need that facility." ADOdb will run PDO drivers quite happily, but on
current information the performance of the PDO drivers is slower than
using the same native driver. So given a choice the native one is
preferable and currently essential for PHP4 support.
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.
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?
PDO provides a basic transaction control that hides the transaction
modes. It can't handle retaining the context of the transaction
following a commit or roll back, or selection a more appropriate
transaction mode? CONCURRENCY for reports at a fixed time point over
COMMITTED to handle changes made in other transactions. How does one
switch between a 'wait' and 'nowait' transaction?
The one that prompted this discussion. How do you return a simple handle
to a BLOB object so that you DON'T have to download the whole blob. It
can be useful to hold the blob id so that you only access a sub set of
the data from the blob object. This seems to be missing in PDO?
HAVING to maintain PHP4 support has meant that I have not gone into PDO
with a fine tooth comb, and most of my understanding of the problems of
PDO is based on what has been said elsewhere, but at present I can't see
how some of these fundamental facilities provided by the php_interbase
driver would be mirrored in PDO. I stand to be corrected, and perhaps
when PHP4 has died THEN the supposed advantage of PDO may be a more
attractive development path? But at present there is simply no incentive
to move over :(
Things went quiet :(
Is there anything in my above list this is NOT correct? I do stand to be
corrected about PDO, but at present I can't see how to get around the
limitations even IF the pdo_firebird driver was functional. And I see some of
these restrictions applying to other database engines as well?
--
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