[wp-hackers] GSoC Proposal: Multiple RDBMS support
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
> The point here is to introduce database abstraction transparently
> without growing WordPress' minimum requirements and breaking existing
> 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
The minds of the commit team have changed before, so maybe they'll
change their minds on allowing higher abstraction.
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