Re: [Proposal] DB_OO

Lukas Smith wrote:

What is the benefit if limiting the scope? I mean why cant you just not use the " features like table joins, field validation"?

Simplicity. You don't have to feed the package a lot of data which would have to be fed "manually" by the developer -- it's too hard to extract some stuff in an uniform fashion from all RDBMSs system catalogs (foreign keys, validation rules, etc).

GPL is not compatible with PHP userland code as this would result in licensing issues with all closed source code that might be distributed along with any GPL'ed userland code. Therefore we only allow LGPL, PHP, BSD and similar licenses into PEAR.

I'll gladly relicense it under LGPL.

Finally I think we have that area covered fairly well with DataObjects and QueryTool. You will have to make it more clear how your packages differentiates itself from these classes and why any missing features cannot be added to these packages. Please also look at the recent thread on DB_Simple as this seems addresses a similar subsection of the PEAR package repository.

QueryTool covers a completely different ground. It aims to be an interface for building SQL queries that sidesteps RDBMSs peculiar behaviours. On a layered design, I'd place it above DB and below DB_OO. Using QueryTool for SQL building within DB_OO is a refactoring I've had planned for some time. I can't find anything on DB_Simple. Google returns only stuff on LiveUser's DB_Simple class, and the archive's search engine floods the results with any message containing "simple". Can you point me to any spec document? DB_Simple, judging by the name, may be what I designed. The main difference is probably that DB_OO is up and running, and has been for a long time. Where I may hit a sensitive spot is with DB_Dataobject. I'm not aiming at replacing DB_Dataobject, so please don't grab stones just yet ;-) DB_Dataobject is quite good, and, as it grows in features, will be the standard data abstraction layer for large applications. However, PHP is a scripting language, and should provide a quick way to access relational database storage, for smaller apps. DB_OO provides such a way, good enough for a large set of uses, and very very simple. You can get a class for manipulating a table in three lines of code: $dbOo = DB_OO::getSingleton(DB_DSN); DB_OO_ProxyFactory::generateProxyFor('person'); $person = new DB_OO_PersonProxy($dbOo); The big question is: can this be built into DB_Dataobject? It can. However, under the present conditions, I wouldn't. Why? The two packages are in a very different evolutionary stage: Judging from mailing list posts, DB_Dataobject is under heavy development. it will probably change a lot, evolve new features, perhaps change structure somewhat. DB_OO, on the other hand, has been feature stable for the last eight months, and is very solid. I'd plan on merging the packages in the future, but not right now. Hope I've answered your doubts. Cheers, Sérgio Carvalho --------------- Portugalmail Multimédia, Lda http://www.portugalmail.pt/