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

On Tue, 2001-11-20 at 04:18, Manuel Lemos wrote: > Hello, > > Paul Cooper wrote: > > > > On Sat, 2001-11-17 at 16:54, Manuel Lemos wrote: > > > > > There is no great point on using database abstractions unless you want > > > to develop database independent applications by using the same API. The > > Well I'm just a lowly developer, I just use PEAR db, I didn't develop it > > so I could be wrong about this but .... the reason I use PEAR db isn't > > to try and build database independent applications - it's simply to make > > my life easier so I only have to remember/learn one api, rather than > > keep reminding myself of the subtle differences of mysql_query, pg_exec, > > etc. I think of PEAR db as a unified api rather than an abstraction > > layer - that's why it'd would be cool if it were ported to C/C++ php > > extension. > I couldn't agree more with Paul on this one > 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, 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. > > > > 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. > > > 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. > > > 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 cooperation. I don't mean to be harsh but if you want to cooperate try integrating 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. yavo