RE: [PEAR-DEV] one abstraction layer (my proposal for)
| From: | Lukas Smith | Date: | Sun, 02 Dec 2001 12:45:55 +0000 |
| Subject: | RE: [PEAR-DEV] one abstraction layer (my proposal for) | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-3286@lists.php.net to get a copy of this message | ||
> Goals
> =====
> 1) User selects mode: speed or portability (default)
>
> 2) Speed:
> 2.1) Non critical features are included by demand
I would want this for the "portability" mode as well.
[..]
> 4.3) Secuencial & Non Secuencial Row Fetching
just a question: whats the purpose of non sequencial row fetching?
Aside from legacy support is there really a need for this?
Most people on this list said the don't use it.
This is important to figure out for what is core and what should be
loaded on demand.
> 4.8) Datatype conversion functions
> 4.9) Data quoting (manual & automatic)
What exactly do you mean by data quoting? Generally quotes and such
should be done by the datatype converter. I generally like quotes around
my integers but not alls DB's support this. Actually I only know that
postgresql and mysql do it.
> 4.13) Results cache
(as a side note: I would want any thing that serializes to be cluster
capable. I am also currently working on data containers where I can
throw parameters into the db to be used later. Like when I have a
preview etc. Nothing special but I need this for files and passwords
that you don't want/cant place in a hidden field)
> 4.14) SQL language builder/helper/parser (?)
What do you mean by this? A query object that could be build one by one?
> 4.15) Database Manager (create/drop of databases, tables, sequences,
> ...)
indexes ...
I assume you include xml schema under this?
> * Development open to any experienced developer willing to contribute,
> the
> code will reside in the PHP CVS and the communication in php-db or
> pear-dev.
I hope the tone of this list is not always like it has been since I
signed up on Wednesday (and I will install a filter for those duplicate
emails *g*).
> - I'll ignore flames or statement out of pure technical (please keep
> them in
good ...
> - 80% usable in two-three months
>
ouch, then again your suggestions do increase the scope quite a bit.
Lukas Smith
smith@dybnet.de
_______________________________
DybNet Internet Solutions GbR
Alt Moabit 89
10559 Berlin
Tel. : +49 30 83 22 50 00
Fax : +49 30 83 22 50 07
www.dybnet.de info@dybnet.de
_______________________________