[wp-trac] [WordPress Trac] #37692: Introduce WP_Database_Table base class

[WordPress Trac]

#37692: Introduce WP_Database_Table base class
-----------------------------+-----------------------------
 Reporter:  johnjamesjacoby  |      Owner:
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Database         |    Version:
 Severity:  normal           |   Keywords:  2nd-opinion
  Focuses:                   |
-----------------------------+-----------------------------
 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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37692>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform