Thies
>     how is that going to be different from PEARs or the dbx one?

i was actually inspired in part by PEAR, so ALISON (Abstraction Layer In
Search Of a Name) is a superset of PEAR functionality. in addition to
current PEAR functionality i've added the following (not exhaustive, and in
no particular order) :


* an upper (PHP) level and a "C" library so that other module writers can
incorporate the db layer

* a PEAR/JDBC/ADO type object model
    drivermanager(DB) -> driver -> connection - resultset
                                                      |
                                                 statement -> resultset

  for many common operations, users will only need to go as far as the
connection level.

* a resultset implementation with internal buffering to allow bidirectional
scrolling for all supported backends. In addition, the resultset can operate
in "disconnected" mode, meaning , for instance, that we can create non-db
resultsets from PHP (or "C") code. resultsets also feature multi-column
sorting ( eg. rs->sort("name asc, id desc") ), and im currently working on
implementing saving and loading from file (or streams when Wez is done).
this will make resulset caching ultra simple.

* resultset cloning (copy a resultset into a disconnected resultset with the
same structure and data)

* resultset column binding to PHP variables. navigation will cause the
related PHP variables to be updated.

* a (hopefully) more resource-friendly connection handling mechanism. under
single process multi-threaded servers, we will be able to strictly enforce
the max-connection constraints. persistent connections will have an idle
timeout and be subject to periodic garbage collection.

* runtime dynamically loadable drivers. just place the driver .so or DLL in
the extensions directory and it becomes available for scripts to use. this
will be controllable at compile time or in PHP.ini

* metadata support to make management tools and UI generation easier

* wider support for underlying database backend. drivers can implement
additional functions which are accessible from PHP through OOP overloading.

* consolidation of common code into a unified framework. driver development
becomes easier.

* other stuff i cant think of right now

l0t3k



Thies C. Arntzen <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Wed, Oct 17, 2001 at 12:03:44PM -0400, lo-tek wrote:
> > A new OOP database abstraction layer (in C) is in the works.
> > Should be ready
> > in 2 or so months...
>
>     how is that going to be different from PEARs or the dbx one?
>
>     tc




-- 
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]

Reply via email to