Hello, Pierre-Alain Joye wrote: > > Hello, > > Not really an expert in both pear or metabase (just tests experiences). imho one >thing is sure, both got advantage and feel with a completly different approach >(philosophy ?) of an db abstraction layer. > There is many ways to create an abstractions layer, every way will be usefull for a >need and completly useless for another one. Just a question of what people will do, >got many choices increases the global goals of php. > And I just think you will better to discuss the real goals of your own philisophy >and how to make it better. The way of "Mine is better, your not" just makes no sense >(in dev-ml ;). I just read a few weeks ago another thread from Manuel and Markus; I >don't remember any question about the goals, approachs or definitions of "What is a >real Abstraction Layer ? and for which use ?". > Maybe you will better start at this point ? And will follow the threads with all my >attention.
What I think is that an abstraction package is only useful if it provides full database independence for the applications that use it. If you use an abstraction package and you still have to deal with database specific ways of doing things, you'd better not use a abstraction package because you will still have to port your application to run with different databases and the abstraction package may even add some runtime overhead. Metabase API provides as much database independence to applications as possible. It supports a rich data type set that covers almost all types that databases use, including large objects (BLOBs/CLOBs), sequences, transactions, direct/prepared queries, retrieving ranges of rows of select queries result and of course database schema management. What is missing? Stored procedures. If you really want to take the maximum of performance of a database, you need to use stored procedures as much as you can. These will be handled in a special way but also in a database independent manner. Stored procedures are not available in all databases and those that have them have their own procedure language. The plan is to use Meta-programming to generate stored procedures code for each database using an high level meta-language that abstracts a common set of stored procedures commands. The meta-language compiler will be able to generate stored procedures for all popular databases: PostgreSQL, Oracle, MS SQL server, etc... For databases that do not support stored procedures, the compiler can generate normal PHP code that uses Metabase to reproduce the store procedure behaviour on the database client side. As a matter of fact, since it will use Metabase, these client side procedures can be used even with databases that support stored procedures. This will be a subject that I will be addressing in my talk in the PHP Conference next week in Frankfurt. If you are nearby Germany, just get there to learn about it. For now more information about Meta-programming is available at http://www.meta-language.net/ but I am not mentioning anything about database procedure meta-language there yet. Regards, Manuel Lemos -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
