Re: Adoption of Metabase (was Re: [PEAR-DEV]Re:ComparingADODB with PEAR DB, Metabase andNative MySQL)

Hello, Yavor Shahpasov wrote: > > On Tue, 2001-11-20 at 08:41, Manuel Lemos wrote: > > Hello, > > > > doesn't scale (try inserting 2GB data in MySQL). As for Oracle you have > > to insert and empty LOB to make it work. PEAR-DB does not do it. It just > > uses bind variables which is good for upto 4Kb VARCHAR fields. Those are > > not large object fields. > > > > OK you got me there :) > This can be easily implemented though, but the need has not arisen, > in fact AFAIK the only one who has ever asked for such a feature in this list was me :) I don't think that is that easy. If you want to send large amounts of data to the database to store in a BLOB, you need to send it in chunks of limited size or else you will blow the memory space that your process will take. As you may know this is the number one reason why Web servers crash the operating systems: memory exhaustion. Unlike Metabase, PEAR-DB does not provide an interface to stream data from and to the databases. > > I have just talked about this meta-language in Frankfurt's PHP > > Conference just a couple of weeks ago. The database procedure > > meta-language will not be ready soon, but you may find more the whole > > meta-language thing here: http://www.meta-language.net/ . > > > > I'll check it out, bit I think trying to develop a common stored procedure > language is like trying to develop a unified programming language (read people will > alway use their thing.) Actually, that is what is MetaL, abstracting languages. Now, whether people use it or not, that is a different subject. > > What is so complicated about it? Maybe it just does more than you need? > > Just don't use what you don't need. > > > > You've misunderstood me if you can show me a way to do this in metabase > in two lines of code, I'll reconsider > <?php > $db = DB::connect("somedsn"); Yes, DSN is in the todo list. > $data = $db->getAll("some query"); Getting all data selected from a query into an array is a feature being added by Lukas Smith. He had his own abstraction layer. After looking around in all PHP abstraction layers he realized that Metabase is the most complete abstraction layer that there is for PHP, so instead of going with his own, he decided to join Metabase development and add what his layer has that he missed in Metabase. As I said before, cooperating is better than competing. > > Standards will only be standards when everbody agrees with them. They > > way PEAR standards were pushed a lot of people will simply disagree and > > will not adhere. Leaving out people this way the community will not > > grow. > > > > I agree but you should add to that that once standards have been agreed on and used for a > couple of years, you don't just change them because new people come up with arguments > i don't like them or sturdy caps make my eyes weep. That's not the true story. As Jon Parise explained, PEAR standards are just an adoption of Horde standards. I don't recall everybody ever agreeing top them. Just to mention a detail, the discussion of tabs vs. spaces is one of silly aspects of the standard. Each developer has his onw conventions. That is why PHP takes tabs and spaces equally as valid whitespace characters. You will never get people to agree on it is the right convention because any one is valid. Rejecting contribution because of silly conventions like this is a major waste of opportunity. When somebody offers to contribute with his code, the PEAR community should say: "Thank you for your contribution", and not "go away, your code is not compliant with some conventions that we decided unilateraly". If there should be any conventions, those should be the ones that the contributing developer uses. That way, you would have some rules without hurting the feelings of the developers that are only try to improved the PEAR component base. > > My most important point is end with just one database abstraction > > package to let PHP developers write database independent applications, > > just like other people do with other languages. It is silly that PHP is > > different. > > > > And you want that to be metabase, but just as you will not be willing to drop > metabase for some other db abstaraction, the same goes for PEAR::db developer or > ADBDB or any other project. Obviously you neither know Metabase features nor read my proposal message. I did not tell anybody to drop PEAR-DB, I just proposed to wrap PEAR-DB around Metabase, so your PEAR-DB based code will still work and you could already benefit from Metabase features now, and not in an uncertain future that you don't know if and when PEAR-DB will ever catch up on Metabase features. > > One thing is certain, I don't want to go where I am not wanted. If there > > is no interest in integrating Metabase in PEAR, fine. If not, I don't > > have a problem with that. From the silence of PEAR core developers, I am > > afraid there isn't much hope from their side to cooperate. At least I > > made an honest attempt to cooperate. > > > > Being unwanted is not the issue here the point is that the only proposition you made > was someone else to port metabase to C for you in the spirit of true cooperation > I find that a bit hypocritic, of course I cannot answer that because the question > was not addressed to me. Honestly, I find that porting PEAR-DB to C will not realistically happen in any time soon. Porting Metabase to C will take even more time, but at least you can benefit of its advantages right now by wrapping around Metabase PHP implementation. See the point? > > > these better features into PEAR. But I'm sure that this is not what you have in > > > mind > > > because you think that met abase is much better, and you might be right, but when you > > > come > > > in a spirit of cooperation you must offer something and not expect to get something > > > in return. > > > So don't get me wrong but what exactly are you offering. > > > > Maybe you need to know better Metabase to realize what I am giving away. > > It's about 3 years of development on something that there is nothing > > like that neither for PHP nor for any other language, a database > > abstraction that not only provides independence to database access but > > also to database schema installation and maintence. The details you may > > find about in the manual and the tutorials available from the PHP > > Classes site. > > > > Maybe I was not clear, here. What do you offer than what is already > there. I do not mean to belitle your work I sure metabase is a good > thing but still the question remains. You need to look further on it is the result of cooperation. PHP community has a lot to gain on having only one solid and well documented database abstraction layer. Regards, Manuel Lemos