[wp-hackers] Database Abstraction

[Keenan Tims]

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

A large majority of the (1.5MB) ADODb code is contained within the 
driver modules for the plethora of database engines it supports, of 
which only one is included per run.  The core code is about 140KB. 
Removing source files we don't need for WordPress wouldn't be hard and 
should trim it down to a much more manageable size.  I don't think 
download size is terribly important either.  Performance, however, is. 
I haven't done any independent study, but word on the street is that 
ADODb is quite a bit faster than PEAR, and it's also quite a bit more 
capable, especially when it comes to DB independence features.  The 
overhead of compiling the extra code is pretty negligible; on my rather 
modest machine (850mhz Duron), it's about 40ms.  By contrast, PEAR is 
about 35ms of compilation and the current wp-db.php 5ms.  PHP's own 
internal setup is about 30ms.  Considering the average WordPress run on 
my machine is about half a second, those times are pretty negligible. 
With a bytecode cache, this is even more irrelevant.  Abstracting the 
database access will cause a performance hit, surely, but I don't think 
it will be very bad.  Indirection, even in PHP, imposes almost zero 
performance hit, and the actual code executed should be similar to 
what's in use today.  It'll just be more organized.

I'm not saying we *have* to use ADODb, but I think it's the best 
solution currently available.  It's got a good track record with other 
large projects, does what's needed, and seems to be the fastest code 
available that does what it does.  Besides PEAR, the other viable option 
is to code something from scratch just for WordPress, which I think is a 
waste of effort and probably wouldn't gain anything on ADODb besides, 
perhaps, source code size.  It'd increase the complexity of WP itself, 
and introduce the potential for more bugs.  The ADODb people have spent 
the past few years optimizing what they have; I doubt we can do much better.

Unfortunately PHP doesn't include this functionality in binary, which it 
really should IMO, so we're forced to find some good PHP code to do it.

Or we can stay with the status quo and continue writing cumbersome 
database dependant code in a more database-independent way.  It wouldn't 
be difficult to do all date processing in PHP and have an array of 
queries run through a version of ezSQL for the particular database in use.

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

Me either.  I was just throwing ideas out for comments.  I prefer the 
object-oriented approach, but WordPress being almost entirely 
procedural, I thought the existing developers might prefer such an 
approach.  The OO approach does require a bit more planning on the part 
of developers making changes to database code, however.

> Asking a newbie to download ADOdb and install it in the right place would
 > be rather difficult I would imagine.

ADODb has a BSD license.  We'd be free to include it in the WordPress 
package.  Newbies would never have to know about it.

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

Me too.  I'll defend my own opinions, but it comes down to the 
community's decision, with the approval of the core developers.

-- 
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/20040822/9e8a7cf5/signature.bin