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

Hello, Yavor Shahpasov wrote: > > If you are going to develop database specific applications you have to > > be aware of the differences. Also, PEAR-DB does not wrap around > > everything that you can use from each database. That is why it is a bit > > pointless to use an incomplete abstraction layer, being that PEAR-DB, > > ODBC, etc..., to develop database specific applications, especially when > > you can use the native API to take the most of the database specific > > features, furthermore without the overhead of each database. > > > > Want an example? How are you going to handle blobs or stored procedures > > with PEAR-DB? You don't, you will always have to resort to the native > > client API. > > > > I didn't have problems with mysql or Oracle for binary objects using prepare/execute, AFAIK, PEAR-DB does not provide specific support for binary large objects. It may work with MySQL because its way of handling LOBs is with any string: inline in the query, which is technically wrong because it 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. > I'm a bit sceptic for postgress. As for stored prosedures I resently did some work with > PEAR on Oracle and stored procedures, I had to resolt to native calls betwin > prepare/execute.But you can't speak about database independanse and abstraction when you > use stored procedures can you. You can have a database independent interface to invoke stored procedures. As for the stored procedure language code itself, you can't abstract that at run time because each DBMS has its own language. Anyway, I will start a meta-language project some time soon that will let you use an abstraction of a stored procedure language and the meta-language compiler will convert in the commands of the target DBMS stored procedure language. For DBMS that do not have a stored procedure language it will generate side code that will do the same as of stored procedure but on the client side. For PHP it will Metabase of course. 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 last looked at metabase a the beginning of the year and the reason I > > > chose PEAR db over Metabase is that it appeared* to me that I had to > > > either use metabase totally or not at all - meaning either I had to > > > > That is not accurate. If you don't want to do portable database > > programming, you don't need to use everything of Metabase. > > > > The reason I didn't like metabase is (call me stuipid) because I found it too > over complicated and not simple enough to use easily. What is so complicated about it? Maybe it just does more than you need? Just don't use what you don't need. > > > so what? If you want metabase in pear then you can get the coding > > > standards and make sure your code adhere to it (or simply start a thread > > > moaning about the coding standards, which seems to be the other way to > > > > I don't have time for more silly discussions. A lot of people that > > wanted to include their stuff in PEAR, simply gave up because they do > > not agree with those standards, as they are basically like Jon Parise > > explained an adapted version of Horde standards. That is a silly > > discussion because it prevents people from contributing. Anyway, I did > > not develop Metabase to contribute to PEAR. Metabase was started more > > than a year before PEAR begun. So, I don't want to enter the discussions > > of standards of PEAR. > > > > My point here is that there a lot that the PHP community loose for not > > having just one officially sanctioned abstraction package for > > developing database independent applications. > > > > The thing about standards is that they are just that, standards. Change them > and you loose the whole point. I was a bit disappointed to see some of the > regulars of this list ready to throw them away just because there ware so many > complains about them after the latest (but probably not last) discussion about them. 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. > > > try to get code into PEAR). If you want Metabase rewritten in C as a php > > > extension, then feel free. If you want to write a PEAR db wrapper for > > > metabase so existing apps can easily switch then no one is stopping you > > > - combine that with a fast C written metabase and you'd have a killer > > > feature set IMO. > > > > I don't have the time. My point is that if Stig is willing to spend a > > year or whatever it takes to port PEAR-DB to C, why not porting Metabase > > API instead and benefit from all those points that I mentioned? > > > > So basically you need some one to do the work for you in the true spirit of Absolutely not. It is not really very important for me the port to C. It will take a long time until it would become useful. Believing otherwise is wishful thinking. There are a lot of projects in the Open Source world that fail because of that. People think that just because they can, they will do it. When they realize it will be taking too long they give up. 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. > cooperation. I don't mean to be harsh but if you want to cooperate try integrating I don't have the time or motivation to develop things for PEAR just because it is funny to cooperate. I am no longer a college student so I don't have plenty of free time to spare. What I do is because I need the things for my job. If I am not selling what I do, I don't have a problem with sharing. That is what I am doing with Metabase. 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. > 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. Regards, Manuel Lemos