RE: [PEAR-DEV] [Proposal] DB_OO

> From: Sérgio Carvalho [mailto:sergio.carvalho@portugalmail.com] > Sent: Monday, December 22, 2003 6:47 PM > 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). Maybe it would be possible to achieve the same simplicity in DB_DataObjects if the user doesnt use those advanced features by extending the package? Note that I don’t use DataObjects myself. > 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. Look at the pear-dev archives. You can search them from the pear.php.net page. > 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 ;-) The point is that we would prefer to keep "duplicate" packages to a minimum. Of course sometimes the approach taken to scratch a similar itch is so different that two packages can live that cover similar ground. So what I am driving at is the following: - is it possible to merge your ideas into DataObject - or is the package so radically different that it needs to be a separate package > 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. OK. That should give a solid basis for people that use DataObject (especially Alan) to make comments. However understand that this is the holiday season. So don’t get impatient if other replies take a while. Regards, Lukas