More DB connectors

[davidjeba]

Can you consider

• CockroachDB
• SurrealDB
• Mongo Realm
• etc?

[SalimF]

Hello, I didn't want to create new issue, but I ask how to install this plugin in server that suppose to not have MySQL or functional WP website?
when I tried to activate it i got this message :-
The SQLite plugin cannot be activated because a different wp-content/db.php drop-in already exists.
I'm sing the older wp-sqlite-db plugin which required copy the file db.php into wp-content/db.php but that not
With this plugin I found it path is /wp-content/plugins/sqlite-database-integration-2.0.0/wp-includes/sqlite/db.php should I copy it again t0 wp-content folder?

[adamziel]

Can you consider CockroachDB, SurrealDB, Mongo Realm

@davidjeba This is a really potent idea! The first step would be identifying all the MySQL-specific constructs in WordPress core. Here's a few examples:

• SQL_CALC_FOUND_ROWS (trac issue)
• DELETE from a, b
• Date arithmetic
• INFORMATION_SCHEMA queries
• Comparing integers and floats
• WordPress Tests_DB tests targeting specific private wpdb methods that are only relevant when MySQL is used

I'm sure there's more than that – these just come from the chat I had with @OllieJones and @aristath last week about this specific subject.

Once the MySQL-specific parts are clear, there are a few ways to proceed:

• Parse them so they can be translated into a different SQL dialect or even a NoSQL query. This may be needed to support all the MySQL-dependent plugins.
• Abstract them out (no SQL, just an abstract method somewhere). This might be necessary in core to avoid the overhead of translating MySQL queries on each request.
• Rewrite them in a more generic way (SQL subset). This could be an alternative to the above.

Furthermore, @OllieJones had an idea to support dedicated table schemas for different database engines – e.g. PostgreSQL could use FULLTEXT indexes out of the box.

I ask how to install this plugin in server that suppose to not have MySQL or functional WP website?

@SalimF I encourage you to start a new issue. Let's keep this one focused on supporting additional DB backends.

[adamziel]

Something else that came up during the chat I mentioned above:

Another thing to contemplate: Some applications out there in the world implement a lot of so-called "business logic" directly in SQL (with a code base containing hairy JOIN statements &c) Others use an abstraction layer -- an ORM -- to implement the business logic. WordPress's abstraction layer is WP_Query and friends, and the SQL layer is $wpdb.

A lot of code violates the layering, using WP_Query and $wpdb.

It's not easy to change a deployed app to move its SQL-layer business logic to an ORM layer. So I think it might be good to approach the problem from a SQL-centric point of view, rather than an enforce-ORM point of view.