[wp-hackers] GSoC Proposal: Multiple RDBMS support
wordpress at santosj.name
Mon Mar 31 05:34:58 GMT 2008
Do you propose an adapter, factory, or registry pattern for
accomplishing this? The way your code looks, it looks like what can
already be done now with replacing the WPDB class with one of your own.
You would have to do replacements of the SQL.
Also, it appears you are talking about Database *Access* Abstraction
Layer and SQL Abstraction Layer. The Access Abstraction is already
accomplished and while pretty damn crappy (you have to support PHP4 you
know), I do think PDO would kick WPDB ass and probably be a lot faster
too. However, PDO would not solve your SQL abstraction and your Access
abstraction is already solved, so there would be no need to do this.
Unless you wanted to remove the global variable usage and allow for one
of the above patterns to have the database replacement in a plugin
instead of in the wp-content folder with a specific name in order to be
included and replace the current WPDB class.
SQL is not that difficult to learn, therefore it would logical assume
that if one knows one SQL language, one can also learn another. Given
that, I think handling RAW SQL instead of arrays would work better.
However you go about doing so would be interesting. However, I don't
suggest your current mockup, because I'll hate you for creating
something so overly complex.
Well, technically it would range from extremely easy but redundant to
extremely difficult, depending on which method you choose. The plugin
would just say, this plugin is MySQL only like in other systems I've
seen. If the user wants another database support, the user can add it
It is a fact, that not coding in strict SQL 92 format and manually
targetting one RDBMS, allows for better support, quicker development,
and better optimization.
It is not a fact that it won't meet most target audiences, want about
companies who already use Oracle and don't want to have to buy a MySQL
server just to run WordPress? Force them to write their own WPDB class
and replace the SQL by regular expressions?
It is not a fact that it will require plugin authors to support RDBMS,
unless it was made a requirement. It would be completely up to the
plugin developer. If that plugin developer only wanted to support SQLite
or Oracle, than that would be their priority and audience. If another
person wanted to add MySQL or another, then it would be added.
Another fact is that it is not very hard depending on how you implement
it, the current implementations only make it seem that way because they
abstract everything and hold your hand. That implementation would be
extremely difficult and not worth the time it would take. An
implementation that is just an array that WordPress looks for the key
for the database and pulls that SQL statement out, would be easy,
I personally, don't care for it, because I don't use any other RDBMS
other than MySQL and my host doesn't support any other than MySQL.
Also, in the person's defense, it is a lot harder to search for keywords
on the mailing list than you think. Some people just aren't all that
good with search keywords which would yield the best results.
Alex Günsche wrote:
> On Sun, 2008-03-30 at 13:51 +0300, Olexandr Melnyk wrote:
>> a little bit late to discuss this, but I would like to apply for this year's
>> GSoC to work on implementing multiple RDBMS support for WordPress. This
>> could be done by moving all vendor-specific SQL functionality
>> to classes, which inherit from a common interface (WPDB).
>> Therefore, all scripts which interact with the database will do it
>> through an abstracion layer, like follows:
> We had this topic a dozen times (please read the archives, guys!),
> and I believe that the consensus was that multiple RDBMS support is not
> a good idea, mostly because of the fact that it is preferable to use
> the advantages of certain MySQL features over portability to DB systems
> that don't meet most of the target audience anyway. Another fact is that
> it would also requite plugin authors to write cross platform plugins.
> This is not only very hard, because you can't expect them to test on all
> major DB systems, but you would again dramatically limit possibilities
> (like e.g. using FULLTEXT indices) where it's actually not required.
> I'd propose, if you bring this topic up again, you would have to read
> the archives (and refer to them, where necessary), and you would have to
> bring new and very good arguments for multiple RDBMS support.
>  http://comox.textdrive.com/pipermail/wp-hackers/
> Best regards,
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