Re: general questions

Hello, Alexander Merz wrote: > > > layers. What I am proposing is to provide PEAR-DB users all Metabase > > features right away without having them to drop PEAR-DB. Metabase > > Your are right, some metabase stuff is really cool. Especially I like the idea > xml schema description, it would be a great benefit for PEAR, but not in > PEAR::DB. > > Why? PEAR::DB is an unified API-Layer for SQL-based Relational-DBMS. But your > xml schema isn't limited to this! Yor xml describes a data structure which can > maybe stored in a file or a ldap-service too. So the xml scheme has to places > in the data container layer, not in the physical container layer, like you > want. I don't think you have studied what each part of Metabase does. The schema parser class parses the a schema XML definition that describe properties of tables, fields, sequences and indexes. I don't know how much of this fits into LDAP or whatever, but the goal was only to support relational databases via SQL. Metabase manager class does many things. It is able to take a description of a schema parsed by the parser class and then install it calling Metabase driver class API functions to do things like creating/altering/droping tables/fields/sequences/indexes. The implementation of these functions is database specific, that is why it is part of the driver classes. Althought it is not very common, these functions may be used by applications at runtime besides install time. That is why it planned to make these functions only available when the programmers tells Metabase factory function to load them. > For the get*FieldValue fetch*Result stuff for PEAR::DB, just write it! If it > exists and keeps the coding standards and your are willing to maintain the > enhancements, it will be commited! Once again, you have not studied how Metabase drivers work internally. These functions are not just wrappers of generic functions. Take for instance BLOB handling. Metabase provides and whole API for storing and retrieving data from streams that are abstracted by Metabase so you can manipulate large amounts of data in a limited size blocks. You are also forgetting what is done with prepared queries which is the opposite of what result fetching but it requires a complete new set of separate functions. What this means is that it would take a lot of time and work to port these functions to PEAR-DB and make the metabase manager class use PEAR-DB. It is outside of the question to have me do it right now. It would take months. Since I am not doing this for anything that I really need or have my work depending on this. I can't justify doing it now, if ever. I do not oppose that someone does it, after all Metabase license is BSD, which basically means "do whatever you want with the code", and several times many features of Metabase have been "borrowed" by PEAR-DB authors. Just be warned that it will takes months to achieve if you work continuously on it, which usually is never the case of PEAR-DB authors because they usually don't have all the time to do it. So, my proposal is to work on something that would take much less work that is to wrap PEAR-DB around Metabase now, and if all goes well port Metabase API to C taking whatever it takes later. Meanwhile, PEAR-DB API could be expanded to take advantage of Metabase features that it does not provide. I think that this proposal is much more realistic to achieve with results much sooner than porting Metabase features to PEAR-DB. If not, Metabase features would already have been available in PEAR-DB now because after 2 years of development it already had time to cacth up, don't you think? Regards, Manuel Lemos