[wp-hackers] GSoC Proposal: Multiple RDBMS support

Jacob Santos wordpress at santosj.name
Mon Mar 31 14:59:35 GMT 2008

Olexandr Melnyk wrote:
> On 3/31/08, Jacob Santos <wordpress at santosj.name> wrote:
>> I do like the fluid chaining. I use it in a current project with decent
>> enough results.
> Could you elborate on what you mean by "fluid chaining"?

Fluid Interface. Chaining is the process of returning the reference to 
the same object to allow for the fluid interface pattern.

$mysql = WP_Factory::getDatabase();

$userClause = new WP_Database_Clause();
$passwordClause = new WP_Database_Clause();

$sql = new WP_Database_Sql();
$sql->select()->columns( array('username', 'somestuff' => 'stuff') 


> It also sounds like your be reinventing the wheel. However, I do suggest
>> you look at the Zend Framework and the DB component to see how they do
>> it. You might not learn anything you don't already know, but it would be
>> interesting, since they are basically reinventing the wheel also.
>> ...
>> However, I like Alex said, this probably will not be accepted, because
>> it will have to support PHP4.3 which is a requirement of WordPress at
>> this moment and in order to do a Google Summer of Code project for
>> WordPress, it will have to support PHP4.3. Also, it is not probable that
>> your project will be included into the core.
> Is there anything technical that would stop it from being included as long
> as WPDB interface remains backwards-compatible, with several methods added,
> and if existing plugins will (at least) remain working with MySQL?

I only have one technical objection. You'll have to talk to the commit 
team. If they don't want and from past discussions it appears that at 
least Matt doesn't and if you don't impress Matt, then abandon all hope 
ye who tries to get your work committed.

The technical objection to higher abstraction of the RDBMS SQL to allow 
for dynamically converting SQL to any database is slower than anything 
that is hard coded. You gain the advantage of an easier interface 
(arguable). You will have to convince others that your solution wouldn't 
slow down the process as much. You will also have to prove that your 
solution is easier than writing SQL, I'll give you similar arguments 
against using something like Smarty in WordPress.

Other implementations that I've seen tokenize the SQL (in PHP) and build 
up the SQL for any number of RDBMS. Other probably do the find and 
replace method, which is already available.

I didn't care for the last discussion on the subject and I probably 
haven't read every discussion. However, you'll have to read the back 
logs and counter those other arguments.

> If you start coding it now, then by the time PHP5 is the minimum
>> requirement, then you'll already have your project finished or mostly
>> finished.
> The point here is to introduce database abstraction transparently
> without growing WordPress' minimum requirements and breaking existing
> plugins.
> We could probably reuse database abstraction layer code from CakePHP, which
> supports PHP 4.

Okay I see, the WPDB would work as it does now as would any object built 
from it, except a few new methods will be added. Might be a good idea.

In all honestly, I have a few projects that also won't ever be committed 
to core, so I kind of know where you are coming from. I'm just not 
holding my breath on my improvements being committed. At least if the 
code exists, then at some point when the minds of the commit team 
changes on the subject matter, there will be existing work to derive a 
solution from.

The minds of the commit team have changed before, so maybe they'll 
change their minds on allowing higher abstraction.


Jacob Santos

http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2

Also known as darkdragon and santosj on WP trac.

More information about the wp-hackers mailing list