Introduce WP_Database_Table base class

[johnjamesjacoby]

I've always thought it odd that WordPress only versions blogs, and not each individual database table. On one hand, it's great that the schema changes rarely enough that WordPress core would not get a lot of use out of it. On the other, many plugins would benefit pretty hugely from a smart base class that encapsulated a lot of the procedural work of having custom database tables and maintaining a schema.

BuddyPress, for example, comes with several object & metadata pairs, for groups, activity, friends, profiles, messages, notifications, etc... It currently takes WordPress's approach of having a big-dumb installer and a bunch of tangled together upgrade routines. I'd love it if each component could manage it's own schema on the fly, with it's own upgrade routines and database table classes to separate the responsibilities, but without needing to setup admin_init hooks and version_compare() checks for each component.

Django has something similar currently, as do other open-source projects like Piwik, GitLab, Mattermost, etc...

---

I'm imagining that each core database table would extend the WP_DB_Table class, each with their own db_version and their own methods for upgrading to newer versions.

Global tables (like wp_users) would use site_id -1 in the wp_sitemeta database table to distinguish them as global, and not per-network or per-site.

---

This way, when a plugin like WooCommerce wants to introduce new database tables, they just extend the base class, pass in an array of column-keys & attributes, and the base class would handle the $wpdb table registration and all of the other bits and bobs.

Eventually... eventually it could get paired up with some kind of a WP_Base_Query class to automatically handle cache-key assignments, and generate basic crud methods based on the parameters in the associated WP_Database_Table extension.

---

I think this becomes particularly useful in REST applications, where WordPress's APIs can be used and extended for any manner of scalable data storage outside of the core database schemas.

Obviously this is a huge idea with lots of moving parts, and without a core need ideas like this are pretty slow on the go. I am already starting to do something similar in my own plugins though - just without the base class - and it feels much easier to maintain each plugin knowing there is a similar convention between them.

See: ​https://code.flox.io/stuttter/wp-site-aliases/blob/master/includes/class-wp-site-aliases-db-table.php

[jdgrimes]

#37656 brought up better bootstrapping for plugin updates, so I guess it is related.

[johnjamesjacoby]

See: ​https://github.com/stuttter/wp-db-table