[wp-hackers] Database Abstraction

[Bobby]

Keenan Tims wrote:

> 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?
>
>------------------------------------------------------------------------
>
>_______________________________________________
>hackers mailing list
>hackers at wordpress.org
>http://wordpress.org/mailman/listinfo/hackers_wordpress.org
>  
>
Actually, this was a large topic that myself and another developer 
discussed for wp-eXtended, but we haven't really started anything 
because there is a large amount of code to port, and because of the way 
that different databases handle things such as mysql's auto_increment 
and date. We did decide on using the ADODB Database Abstraction Layer, 
we just never got around to working on it yet, but problably will 
sometime within the next 1-2 weeks. From the sounds of it you've looked 
into it a lot more than I have to date, and might even take less time 
porting the code. I'm interested in hearing your ideas of how to port 
the $wpdb class.

Robert Deaton