4 ms·
I certainly hope they do not add an ORM into WordPress. It would add a big layer of complexity and break nearly all plugins that interact with the database.
by ThinkBeat 4y ago
I certainly hope they do not add an ORM into WordPress.
It would add a big layer of complexity and break nearly
all plugins that interact with the database.
This can be mitigated by maintaining and updating both
the database access as it is today as well as the ORM
layer.
Which would probably mean some plug-ins using one and some
the other. Perhaps over a long enough time scale converging
for the ORM.
Right now debugging problems with the interaction between
database and application are blessed by it being fairly transparent
Adding a messy layer in between adds complexity not worth it
unless it is required to add support for many other databases
and I dont see any reason why it would be beneficial for enough
users for that to be worth it.
Introducing just SQlite will expose a lot of problematic edge cases.
since MySql provides a lot of feature that Sqlite does not.
(which in most cases is a very good thing)
- zapt02 4y agoI don't think this is a correct take, because most plugins that interact with the database already use the abstraction functions, eg get/set_option(), WP_Query, get_post_meta() and so on. These would all work out of the box. The only plugins that would not work are: 1. Plugins that register their own database tables (however there already exists prior art such as https://github.com/aaemnnosttv/wp-sqlite-db https://github.com/aaemnnosttv/wp-sqlite-db for handling these cases) 2. Plugins that do direct queries against the standard database schema (broadly either for invalid (bad code) or performance (valid but slim use case) reasons) Also, WordPress would of course keep the old query functions around and they would likely add a tag to the plugin repository so authors can mark plugins as supporting thes new ORM features. Great idea in my opinion!