[wp-hackers] Database Abstraction

[Keenan Tims]

After spending some time porting WordPress to Postgres, I'd like to help 
out with the database abstraction to keep the amount of work required in 
the future minimal (and of course improve wordpress ;)).

I've scanned the list and support forums and I can't seem to find any 
sort of plan for this, so I'm just going to go ahead an propose how I 
think it should work and see what there is to be said.  I obviously 
don't want to waste a ton of time on something like this without support 
from the existing developers...it's a rather large undertaking and if 
the code weren't merged into WP it'd be a lot of wasted effort.

I haven't done any in-depth planning (and I'm not terribly familiar with 
the WordPress internals), but I'd like to do something like this:

The current wpdb class and ezSQL should be abandoned in favour of a new 
model.  The main application code will access a brand new wpdb class 
that implements context-specific methods for any sort of data access the 
application may need.  Rather than specifying queries directly in 
application code, conditions will be passed in an associative array to 
the data access method.  Data access will be through some DB access 
layer to make porting easier and provide useful functionality to the 
database programmers, and the dependant classes will extend the access 
layer to give direct access to the API.  My own preference is ADODb, 
however, PEAR or PHPLib could easily be used.  I'd prefer to avoid ezSQL 
due to it's lacking functionality and rather inelegant interface and 
solution to accessing more than one database.  Just having the same API 
implemented for each database is insufficient IMO.  Using ADODb would 
also give database programmers some 'easy way out' solutions to common 
problem areas like dates, and a nice data dictionary class to hopefully 
make the installer portable.

The other approach is simpler and easier, but IMO not as flexible.  That 
is storing an array with the database dependant queries in a file and 
including it based on preference.  Then using a library with some 
portability functions to access the database with those queries will 
give us relatively simple independence.  But it still requires WP itself 
to be aware of the database access, and makes the interface for database 
access much less elegant.

For now one-time porting the installer and upgrade scripts should 
suffice.  I'm told that there are plans to clean up that mess, and if 
improved database access is available for that, it should be pretty easy 
to make it portable at that point.

Now I'm willing to start hacking on it right away, but I'd like some 
input and support before I get started.  It's more work than I can do in 
a reasonable amount of time alone...and other developers will obviously 
need to head in that direction too if we ever want to get rid of all the 
database dependent code in WP.  I'd love to see 1.3 be fully portable.

Comments?

-- 
Keenan Tims
ktims at gotroot.ca
PGP: http://www.gotroot.ca/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : /pipermail/hackers_wordpress.org/attachments/20040820/ce1013b5/signature.bin