Lester Caine wrote:
Not into Oracle ;) , but it answers the main questions. PDO is not planned to be a replacement for ADOdb.
No. That is something for another layer. PDO is intended to be a very light layer with minimal interference.
Until all engines can use the same SQL there is little point in a generic layer that means you have to re-engineer the queries when ever you switch engines ? Unless it is very much faster than the existing drivers, in which case I'd switch the Firebird ADOdb driver to use it :)
So I'm looking at a different level of the Abstraction Model.
It's bad enough catering for the differences AFTER ADOdb has taken off the rough spots ;)
There are two parts to database abstraction.
1) client API 2) SQL
PDO addresses 1) quite nicely and takes very specific stabs at 2) .. mainly prepare/execute, error codes, LOB
Anything beyond that gets to ugly that its probably more feasible to do in PHP userland anyways. This was the original intention of the extension and it has remained unchanged todate.
We are lobbying Oracle to add limit support, but thats another topic.
BTW: I am working on PEAR::MDB2 to become as API compatible as possible with PDO. This has the benefit of giving a PHP4 package that people can use today with the PDO API so that they can move to PDO easily once they are ready to make the jump to PHP5. Also this will enable people to easily move to MDB2 from PDO if they need the additional abstraction. At the same time I will eventually also provide PDO based drivers which should be much improved in speed (and maintainability) compared to the old drivers. Contributions are welcome :-)
regards, Lukas
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
