Re: one abstraction layer (my proposal for)

Hi, Here is my point by point review of the proposal. Tomas V.V.Cox <cox@idecnet.com> wrote in message news:3C09B3B8.FCEE1F82@idecnet.com... > Goals > ===== > 1) User selects mode: speed or portability (default) > Of course SPEED is my preferred default. > 2.4) C rewrite when stable Great > > 3) Portability: > 3.1) All the features are avaible in all the backends (emulated when > posible and native is not avaible) > > 4) Features (in no special order) > 4.1) Unified and Extreamly Easy OO API Already available in PEAR DB. > 4.2) Prepare/Execute Already available in PEAR DB. > 4.3) Secuencial & Non Secuencial Row Fetching Already available in PEAR DB. > 4.4) Quick data fetch (get*() methods) Already available in PEAR DB. > 4.5) LOB support A must have for Oracle. No one using MySQL or PostgreSQL would be particularly worried about this. I have a proposal: > 4.6) PEAR Error support and abstracted database error messages Already available in PEAR DB. > 4.7) Information: about the database internals, the results, > the errors You can copy and paste from ADODB anytime. > 4.8) Datatype conversion functions You can copy and paste from ADODB anytime. > 4.9) Data quoting (manual & automatic) Automatic is very difficult to do unless you can query the database internals for field types. MySQL/PostgreSQL is trivial as numbers can be quoted, but other databases will object. Definitely only in "portable PEAR DB" please. > 4.10) Limited queries Already available in PEAR DB. > 4.11) Sequences Already available in PEAR DB. > 4.12) Transactions Already available in PEAR DB. > 4.13) Results cache Already available in PEAR Cache (although I think it should be unified into PEAR DB). > 4.14) SQL language builder/helper/parser (?) Very difficult to get right except for basic stuff. > 4.15) Database Manager (create/drop of databases, tables, sequences, > ...) This should be separate set of classes, not within the DB_Common hierarchy, otherwise we will have code bloat. > 4.16) Strong and deep test suite Already available in PEAR DB QA I hope ? > 4.17) DocBook Manual, PHPDoc API, translations and annotated manual Already available in PEAR DB. > 4.18) Easy distribution/installation with the Pear Installer I don't know much about this. > * (4.8) Data Type conversion to be done by a more generic class > PEAR_DataType > (suitable to be used in other enviroments too, like xmlrpc, etc) Sounds good, but you need to define what abstract data types you want to support. The main issue is dates and datetime, because Unix timestamps are not very good equivalents for dates unfortunately. Most other database types have natural PHP mappings. > * (4.13) Results cache to be done by the PEAR_Cache class I have mentioned in another posting that disconnected recordsets provide more flexibility because they can be used as cached recordsets. Also you can store all the records in a query using a disconnected recordset, which is useful for numRows() and limitQuery(). Regards, John