[wp-hackers] Database Abstraction

[Stephen Cropp]

I know that this is just asking for trouble on my part, but I disagree. 
Something 'like' ADOdb might be nice, but not ADOdb itself. It truly is 
just too heavy and too cumbersome.

I agree, abstraction would be a very very good thing, (we had this 
discussion in #wordpress when Keenan first told us about his port to 
PostgreSQL and that wasn't the first time) but ADOdb is just bloatware 
when it boils down to it. I'd be much more in favour of a lighter 
solution if possible.

As Keenan found out, there are a lot of places in the WP code that rely 
on MySQL's own functions to achieve certain things. This makes 
portability difficult, but it also means that if a function is altered 
(worse) in the future by MySQL AB, WordPress would break. Having the 
abstraction there, and being database independant would be a huge plus, 
but adds to the size of the code while often decreasing the speed of the 
code as well.

PEAR::DB is one suggestion that I've seen floating about, and thats not 
entirely a bad idea. Everyone can easily access it. If they have PHP 
running WordPress, they can definitely access PEAR::DB as it requires 
PHP 4.x or better. However, the only thing that kinda bothers me about 
this option is that we'd either have to include all the appropriate 
modules (DB::mysql, DB::pgsql, DB::mssql and so on) with WordPress - 
which bloats the release - or we trust that the end user has the ability 
to install them on their own. This would apply to any abstraction layer 
we chose. Many of the users are first time users that have no experience 
at all running a website (the point and shoot installers) or would be 
lost trying to install PEAR modules in general. If their host even lets 
them do so.

 I do not like the idea of storing the queries in an array in a seperate 
file for each DB type though. That becomes exceptionally messy as you'd 
have to manage multiple files just for the one update. Far better to 
have a variable in wp_config.php that defines which database type to use 
and then have that work with a 2D (or deeper) array within a single DB 
abstraction file. That way you could update queries in the same place 
all at once. But even that is not very elegant.

No matter what gets done, its going to be a very big change and its 
going to hurt as far as size goes. As far as performance goes, that 
becomes just as painful for most abstraction layers. Adding complexity? 
Need I say more? ;-)

I'd love to see this openly discussed with good and bad points presented 
for everyones options and suggestions. Maybe even a wiki page that could 
be used to narrow suggestions down to just the few top of the list. I 
know Matt has voiced his opposition to ADOdb and I fully agree with him. 
Its big and bloated and while it might make coding nice and easy, on its 
own its about 1/3 larger than WordPress itself. We'd be more than 
doubling the download size immediately. Asking a newbie to download 
ADOdb and install it in the right place would be rather difficult I 
would imagine.

I'd love to hear other peoples input as well. Thats just my $0.02 on the 
matter.

Per Søderlind wrote:

>Thumbs up for ADODb
>
>../Per 
>  
>