[bretthopper]

I'm highly in favour of this, but wanted to point out an important implementation detail in case people don't want to look through the code.

Since WordPress doesn't have a database abstraction, SQLite integration is done by transforming the SQL query strings meant for MySQL. This not only means doing regexp matches with string replacement, but trying to emulate MySQL functions with either SQLite equivalents, or in the worst case, in PHP application code.

[smcnally]

This sqlite abstraction has been working well for me: https://github.com/aaemnnosttv/wp-sqlite-db

it’s one file — ‘db.php’ — you swap in for the core file. From there, it’s mostly been seamless. ~20% of the 5k LOC, is “Method to emulate MySQL XXX() function.”

Less than that for query parsing, regex & rewrites

https://github.com/aaemnnosttv/wp-sqlite-db/blob/master/src/...

[rawoke083600]

Lol after decades of programming, there actually WAS a need in THIS project to 'abstract/subclass' the db.code. You know in case we want to switch dbs in the future.:)

[ilyt]

... of course it would be fucking cursed, it's wordpress

[noahtallen]

Interestingly, WordPress does (kind of) have a database abstraction. The way you get it is to format your data model as a “custom post type,” and then you basically get an object store with various predefined functions to access it… kinda works for more use cases than you’d think, but also weird!

[MuffinFlavored]

> Since WordPress doesn't have a database abstraction

How hard would it be to "add one"/refactor?

[tyingq]

It doesn't even currently use real parameterized queries...it has a method that sounds like they are real, but they aren't...just a really hairy bunch of string escaping. They really need to re-write the database layer from scratch.

Behold: https://github.com/WordPress/WordPress/blob/master/wp-includ...

[ezekg]

This brings back bad memories. I shouldn’t have reminded myself of what WP code looks like.

[CharlesW]

> How hard would it be to "add one"/refactor?

From a technical POV: This is potentially straightforward if WordPress leverages (and "blesses", for plug-in developers) a proven abstraction layer like Doctrine DBAL that supports both MySQL and SQLite.

From a non-technical POV: There are tens of thousands of WordPress plug-ins, and even updating the top 1,000 that are good/popular will be a multi-year lift.

[georgyo]

plug-ins are likely the real burn.

MediaWiki technically supports PostgreSQL and SQLite for many years, but extensions are really MySQL focused making it the only real choice.

[AdamJacobMuller]

> How hard would it be to "add one"/refactor?

To add one? Trivial.

To refactor all of WP core to use it? I could probably do it in a week or two of focused work.

To enable all plugins and wordpress themes to use it? It is, literally, probably a million times more LOC.

[bretthopper]

I'd guess very hard. But just refactoring the WordPress codebase isn't enough, you'd ideally want every plugin to adopt the new API as well... Although you could always keep this implementation as the fallback behaviour.

[unity1001]

The problem is not adding one. The problem is that it would complicate the infrastructure. From adding more performance requirement to WP wherever it is hosted to the compatibility concerns with plugins. Its a tall tale.

[bombcar]

Probably easier to use MySQL as the db layer and have it use SQLite as the backend store somehow heh.

[maxloh]

PHP is ultra slow anyways.