RE: [PEAR-DEV] general questions

> The constructor can do this too, but its currently a > 'feature' and cannot be guaranteed to work in the future. > Thats why we're using a static function for factoring the > appropriate class. Thx for this reply this was the sort of constructive answer I was looking for. This sounds like a sensible reason. To those other reply's to my questions: it really does not make sense giving me answers like that ('consitency' etc.)... throwing back answers like that does not help anyone .. I assume this is not a snob list so don't welcome newcomers like this. Very unfriendly. Then again I should have probably done a search before asking. I was sort of disappointed that stuff like that is not mentioned in the documentation (and once I have understood the Pear way of doing things I will hopefully will be able to help improve the currenty docus to make it easier on Pear newbies like myself). 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. 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. We have already done some modifications to metabase that will fetch A row, a column, a single field or a multidimensional array (for multiple rows) .. so this will be there I will still have to see about clob/blob support and fetching. 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 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) Best regards, 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 _______________________________