Re: DB, MDB2, PDO - Future of DB-Abstraction in PEAR

Davey Shafik wrote:

I just want to make it clear, its not possible to *extend* the main PDO object easily, because the PDO::__construct() method is marked final, you cannot set your own constructor - the reasoning being that if you extend it, and fail to call parent::__construct() in your class, it causes a segfault. I personally feel this was a kludge fix. Oh well, __call() is my friend.

But it's not very difficult to use a factory methode or something like that. I don't need to add anything to the constructor.

Maybe you would like to check out Crtx_DB_DataObject [1], I've taken ideas from all over and I feel that I've melded them into a very nice lightweight package. Although still beta, its working pretty nicely for me and has a pretty good test suite.

I have read about that package but have never looked into it in detail. I will look at it again, but the point why I do not use a package like that is the structure of the application I develop, which has a very complex database-structure. There are about 100 tables, sometimes I need information from about 20-30 tables to display a page with lots of joins... Sometimes it's really difficult even to get the needed data using plain SQL (in an effective way). Using such Data-Objects or other things like Propel/OR-Mapping makes these tasks even more difficult to me. Or do you think your class would fit nicely into such a more complex scenario?

I have done some *very* minimal nextID() abstraction, by that I mean, if it doesn't work without specifying an argument to PDO's nextID() method and its not PostgreSQL it won't work.

What is "PDO's nextID() methode"? btw. is there any resource where I could find out which PDO-Driver supports which PDO-function (beside reading *and understanding* all the C source-code)?

I would just like to voice a thought I've had on Crtx_DB_DO, I don't want to bloat the class with lots of portability stuff - its the reason I've used PDO directly instead of MDB2. However, I'm happy to do some very basic checking for popular DBs with *similar* enough syntax and support those in this core class.

sounds interesting

Then I would rather create say a Crtx_DB_DataObject_Oracle class tailored specifically to Oracle, same for MSSQL - these are enterprise level DBs, and its pretty safe to assume that you are working with lots of data when dealing with them, I would rather not bog them down with any abstraction code at all, its all hard coded specifically to those DBs.

OK, for such DataObjects it makes sense. But I only need LIMIT support - comparable to DB/MDB2. best regards Andreas