"Stig S. Bakken" wrote: > > Joao Prado Maia wrote: > > > > On Wed, 21 Nov 2001, Martin Jansen wrote: > > > > > On Wed, 21 Nov 2001 09:19:44 -0500 (EST), Joao Prado Maia wrote: > > > > > > >If PEAR::DB is not abstracting the database what is the purpose of such a > > > >library ? > > > > > > To ease the life of lot's of programmers. > > > > > > > I probably used a bad choice of words. What I really meant was: What is > > the objective of PEAR::DB as a database abstraction library ? To abstract > > as much as possible like Metabase already does, or to provide a unified > > API to databases and leave the implementation related to database specific > > to the user himself ? > > > > It's okay to choose the latter, but I believe we should have a unique > > position on something like this, so we know what we are working for. A > > statement like this will be very helpful when people come to the mailing > > list saying that PEAR::DB doesn't abstract LOB's or any other exotic > > feature, as we can just reply "that's not our objective". > > > > Anyway, I think this is a good discussion. > > PEAR DB's objective was to provide a common API. This is why I did not > choose Metabase for PEAR in the first place, IMHO it was too huge and
After almost two years PEAR-DB is still catching up with Metabase features, for instance, sequences, limits in select queries, etc... When PEAR-DB catches up on the current Metabase features it will not be smaller than Metabase. The difference is that it will take even a longer while to catch up than it already took today. What is worse is that it is under-documented and subject of permanent API changes. Take for instance, the recent changes on the way to specify limits to select queries. First, they decide that setting the query limits should be coupled actual query execution. Then they realize that setting the limits of prepared queries have to be done before executing the query. So, the latest solution is doing exactly as it is done with Metabase! If this already like this with limits in select queries, I can imagine how it will be like when somebody finally decides that PEAR-DB needs an interface for handling BLOBs. I guess it will be something like everybody jumping in with their own ideais on how to store and retrieve data from BLOBs, leading to several incompatible versions of the API functions to do that. You have to admit that this is silly. The real problem is that this experimental character of PEAR-DB is annoying to most users because they do not have a stable API to rely on, nor do they have an expectation on when PEAR-DB API will ever be stable and properly documented. So for a lot of people, PEAR-DB is as good as non-existing. My proposal to wrap PEAR-DB around Metabase is exactly to address this current PEAR-DB deficiencies and stop the PHP bad fame of lacking of a database abstraction layer. Metabase API is stable and througly documented. Metabase manual not only documents the features and the functions, but also has a pedagogical approach because it explains clearly with some detail complex concepts like prepared queries, transctions, blobs, etc... Regards, Manuel Lemos -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
