m (capital P dangit) |
Meszarosrob (talk | contribs) m (Update ezSQL link as it does not redirect from the old to the new location) |
||
(One intermediate revision by one other user not shown) | |||
Line 4: | Line 4: | ||
}} |
}} |
||
− | Currently, the official WordPress distribution only supports the MySQL database |
+ | Currently, the official WordPress distribution only supports the MySQL and MariaDB database engines. A number of people have requested support for other database engines, particularly the open-source '''PostgreSQL'''. This page is an effort to summarize the [http://wordpress.org/support/topic.php?id=549&page=1 previous discussion] on the topic, and to get a solid roadmap for supporting more databases in WordPress. |
== Port vs. Integration == |
== Port vs. Integration == |
||
Line 16: | Line 16: | ||
== Database Challenges == |
== Database Challenges == |
||
− | # Current codebase is very MySQL-centric. While WordPress does use the [ |
+ | # Current codebase is very MySQL-centric. While WordPress does use the [https://justinvincent.com/ezsql ezSQL] class to implement database calls, this cannot properly be called an abstraction layer. Differences in SQL syntax implementations among different databases (whether literals are surrounded by quotes, limit query syntax, case sensitivity, [http://phplens.com/lens/adodb/tips_portable_sql.htm etc.]) are not cared for by ezSQL, which simply offers a generic "query" call. This means that a large number of queries would have to be rewritten, a large task. |
# Database driven plugins depend on the current implementation, and also use MySQL-centric code. Even if the WordPress code were to be rewritten to support a full database abstraction layer, any sudden shift in the database implementation will likely break other plugins that rely on database access. |
# Database driven plugins depend on the current implementation, and also use MySQL-centric code. Even if the WordPress code were to be rewritten to support a full database abstraction layer, any sudden shift in the database implementation will likely break other plugins that rely on database access. |
||
# Current standard database abstraction layers ([http://adodb.sourceforge.net/ ADOdb], [http://pear.php.net/package/DB Pear DB]) are very large and complex, they would represent dependencies as large as or larger than WordPress itself. This could reduce WordPress' portability and ease of installation. |
# Current standard database abstraction layers ([http://adodb.sourceforge.net/ ADOdb], [http://pear.php.net/package/DB Pear DB]) are very large and complex, they would represent dependencies as large as or larger than WordPress itself. This could reduce WordPress' portability and ease of installation. |
Languages: English • 日本語 (Add your language)
Currently, the official WordPress distribution only supports the MySQL and MariaDB database engines. A number of people have requested support for other database engines, particularly the open-source PostgreSQL. This page is an effort to summarize the previous discussion on the topic, and to get a solid roadmap for supporting more databases in WordPress.
The most common way of adding support for another database engine to an existing project involves completely overhauling the source code to replace references to one engine to another - creating a port with support for the database engine of your choice.
The drawback to porting WordPress is the difficulty of keeping it in sync with the original codebase and up to date with new features and security enhancements. This can be seen in Keenan Tims's PostgreSQL port of WordPress 1.2 - now insecure and out of date. There is also a more recent port by Erwin Wolff available at Source Forge.
While this is a great first step and sufficient for some needs, a port is not desirable to most users who wish to have the latest security and features available from main WordPress branch. A better solution would be to integrate support for alternative databases into WordPress. This, however, will take a concerted effort from the developers to write queries which port easily, and to get together a good abstraction layer for the database.
Maintain the current development direction. Very little importance is placed on database independence by the WordPress core developers at the moment, so a fork is necessary to support other databases.
Pros:
Cons:
Extend ezSQL to include any necessary abstractions to make MySQL and PostgreSQL work equally well.
This would be a matter of including both ezSQL's Postgres abstraction and their MySQL abstractions in the installation, as well as adding necessary methods to generalize between the two (i.e., a limitQuery method, perhaps others). Rewrite SQL queries throughout to be PostgreSQL/MySQL compatible, and to use custom extensions to ezSQL to handle incompatibilities where they exist. Users would set which database they were using in wp-config.php and not have to think about it further.
Pros:
Cons:
Convert all queries (and blocks of queries) in WordPress to function calls, or more appropriately, object methods, to get that relevant information out of the database.
Support for new databases can be added by adding code for that database to these functions. Optimizations for specific databases when getting certain blocks of information can be added to the relevant functions.
For example, fetching the front page posts and their comment count can be done in one query on databases that support subqueries vs. requiring at least the number of posts shown + 1 queries with legacy MySQL. Legacy plugins should still function when MySQL is being used.
Pro:
Con:
Convert all queries in WordPress to function with a database abstraction layer such as ADOdb or Pear DB.
Pro:
Con:
A number of people (see the previous discussion thread) had proposed donations to pay for development of one of these choices for alternative database support in WordPress.