[wp-hackers] GSoC Proposal: Multiple RDBMS support

Jacob Santos wordpress at santosj.name
Mon Mar 31 05:34:58 GMT 2008


Hey Olexandr,

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

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, 
however hackish.

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[1], 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.
>
> [1] http://comox.textdrive.com/pipermail/wp-hackers/
>
>
> Best regards,
> Alex
>
>   


-- 

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