RE: [PEAR-DEV] Re: one abstraction layer (my proposal for)

> Of course SPEED is my preferred default. > I do not see much point in modes, since I think the goal should be to dynamically load anything used. And this should be achievable. Of course we should list what is a core component and what the other extension packages there are. > > 2.4) C rewrite when stable > > Great just a side note. The dbx project never really seemed to get very far but I emailed them today. > > > 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: ... but portability means that this should be available for all db's or be emulated. > 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. I still don't see much point in separating datatype conversion from data quoting. > Already available in PEAR Cache (although I think it should be unified > into > PEAR DB). Yes, we should not examine if it is feasible to keep this separate. > > > 4.14) SQL language builder/helper/parser (?) > > Very difficult to get right except for basic stuff. Agreed, as I have stated before it is hard to make SQL easier than it already is. But I think this is a bit out of the scope of this project. But this would not be Db abstraction but introducing a new dialect. . Obviously this would make the DB abstraction much easier to do since you actually write the query all yourself. Of course something like this would allow for querying all sorts of differently structured db's as well. > > > 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. > See above statement about dynamic loading. Lukas