RE: [PEAR-DEV] general questions

> It may be "miles away" from PEAR::DB, but there are also "miles" of users > that don't necessarily need or want to use the advanced features of > Metabase on their day-to-day developments (myself included). So please > don't take that for granted, as a reason for dropping the current PEAR::DB > API altogether. Yeah thats why I also feel it is important to only load this functionality when needed ... this is very important if the goal is to in the end have one Db abstraction layer that works for everybody > My point is, we will have to think about supporting the current API on the > new DB, and I don't see a reason for not keeping the current get*() and > fetch*() methods for people that only want to use the PEAR::DB 'classic' > API (myself included) on the new DB. Well in the context of keeping things lightweight I would rather drop the fetch stuff > You don't have to, just use the get*() methods. Sorry, I missed the difference between get() and fetch(), thx for pointing this out. As I have stated I really want this for: Single fields Single Rows Single Columns Multiple Rows Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________ > -----Original Message----- > From: Joao Prado Maia [mailto:jpm@phpbrasil.com] > Sent: Thursday, November 29, 2001 1:33 AM > To: Lukas Smith > Cc: pear-dev@lists.php.net > Subject: RE: [PEAR-DEV] general questions > > > On Thu, 29 Nov 2001, Lukas Smith wrote: > > > A couple of questions about Pear DB: > > To the question of keeping two Db abstraction layers or only one: Yes I > > think it makes sense keeping only one abstraction layer. And since the > > API will have to change for metabase (and this is one of its main > > weaknesses) obviously metabase also has a userbase to think off. > > > > I'm probably not wrong when saying that PEAR::DB has a bigger userbase > than Metabase. I personally know a lot of people / projects that already > use PEAR::DB (including the company I work for) and don't know many people > that use Metabase (except for the BC folks). The numbers really don't > matter though, the important part is that the current API of PEAR::DB is > being used in production and I'm sure that the Metabase API is also being > used. > > > > > Also feature wise metabase is miles away from PEAR from what I have > > gathered looking at the mebabase docs and tutorial compared what I found > > in the Pear DB tutorials in the support section of pear.php.net. Manuel > > has already planned making metabase a bit more lightweight if you do not > > need the advanced functionality. And I have heard that the binarycloud > > team already did some work in that realm with an addition they did. But > > anyways the current Pear DB folks will have to accept the fact that > > porting metabase to Pear will open a whole new world of features. Not > > just the xml schema stuff. So don't expect the Pear way of doing things > > to be the end all be all. Because Pear DB currently isn't. This is just > > a side note. > > > > > > > I don't think that some of the fetch features are needed .. actually > > they some of them are madness imho if I understand them correctly (only > > looking at the API). The way it seems is that Pear DB does sorting and > > researches after the query has been done!? Why? Write queries that get > > you the data you need. I see no reason to support such features on this > > level. This is what the DB is for after all. Tell me if I am > > misunderstanding things here. > > > > I personally always use the get*() methods. I'm not sure if the fetch*() > methods are faster or whatever, so maybe someone else might be able to > answer this one. > > > > I also have one more general question: > > Why keep the execution of the query separate from the fetching? This > > just means one more function call. Is this needed for better error > > handling? Although my function that does the query+fetch could return > > the proper error. And most of the times I will do the same thing for > > failed queries or fetches anyways. I might be terribly missing something > > here as metabase does this also (but in the case of metabase this is > > probably more related to how metabase handles fetches) > > > > > Cheers, > Joao > > -- > João Prado Maia <jpm@phpbrasil.com> > http://phpbrasil.com - php com um jeitinho brasileiro > -- > Precisando de consultoria em desenvolvimento para a Internet ? > Impleo.net - http://impleo.net/?lang=br > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > For additional commands, e-mail: pear-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net