Re: general questions

Hello, Lukas Smith wrote: > Also obviously Manuel suggested that I could do this because he is > really deep into Metal (btw: Metal will be able to do some amazing > things for a Db abstraction layer). Since I wanted to redesign parts of Yes, as I revealed about in my talk about MetaL, I plan to develop a stored procedure abstraction language with MetaL. A dedicated MetaL compiler module will be able to translate that language into stored procedure code suitable for the different types of databases: PL/SQL for Oracle, Transact SQL for Microsoft SQL server, PL/pgSQL for PostgreSQL, etc.. For other databases that do not have a stored procedure language like MySQL, it will generate database client-side code with the current MetaL database module which uses Metabase to generate database independent code. If this PHP database abstraction package convergence effort succeeds, I can justify spending some effort to change the code that is generated for Metabase into code for the database abstraction package that comes out of it, being that something with PEAR-DB API or something improved over it which seems more likely. > metabase anyways and I am also in the process of looking what features I > am missing from metabase, it seemed to make sense to me to also get this > thing under the Pear umbrella. > > Also I will have to look at ADODB .. since everybody is saying how fast > it is :-) (anyone know why?) The only relevant difference is that ADODB has a function to fetch whole rows in a single call just like that function that you have been adding to Metabase. Other than that, ADODB does not provide any datatype translation, so it does not spend time providing the portability that Metabase provides. Of course, without providing portability and still having to put up with ADO-DB interface, it would be faster to use the native PHP API functions. That is what ADO-DB author (John Lim) benchmarks showed. Actually there are no other benchmarks. Notice that John has a commercial database tool to sell that is based on ADO-DB. That suggests that he has plenty of reasons to publish whatever benchmarks that make his ADO-DB package look better than others. The more users he attracts to ADO-DB, the more it increases the number of potential buyers of ADO-DB. Sadly, John refused to cooperate in the development of a single database abstraction layer. This seems to be a ego driven attitude that does not even reflect a good commercial vision that would favour the sales of his database tool. If he had accepted to cooperate in the development of only one database abstraction layer, the potential user base for his commercial tool would have been larger than ADO-DB user base. Anyway, this is just to point out that when people are motivated by "reasons" related with ego, often they loose opportunities that their ego's prevent them to see, like what I just described about the opportunities for John to increase his comercial tool user base. However, it is not too late for him to reconsider. I also notice this ego motivated protective attitude in some PEAR-DB developers. I sense that some seem to be objecting to the idea of having only one database abstraction because somehow at least part of PEAR-DB is also their fruit of their work. So, it is understandable that they feel reluctant to give up on their code even if you can demonstrate that it will replaced by something that is better for everybody. Despite I understand this protective attitude, I think that everybody has to stop and reconsider what is good for all in the end. Each one has to give up on ego motivated "reasons" and be rational for once. There are plenty of opportunities to take the chance on if we have only one database abstraction layer. Part of this discussion was already held 2 years ago before PEAR was started when Metabase was released. I hope people are sensible enough to not take another years or more to converge in a single database abstraction package for PHP for the joy of all. Regards, Manuel Lemos