[wp-trac] [WordPress Trac] #55942: Add a "type" field to the meta and options tables (was: Add a "value type" parameter to get_option() and get_metadata())

[WordPress Trac]

#55942: Add a "type" field to the meta and options tables
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  6.3
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------
Changes (by spacedmonkey):

 * component:  Options, Meta APIs => Database


Old description:

> Update: This ticket had to be somewhat repurposed as it became clear that
> with the initial approach there's no good way to ensure full backwards
> compatibility in `get_option()` and `get_metadata()`.
>
> The initial idea to support "strict" types of the options and meta values
> remains the same, but the implementation has changed. The new approach is
> to add another parameter to the above functions. This would ensure 100%
> backwards compatibility and at the same time will provide approximately
> the same benefits:
>
> - Consistent types of the return values from `get_option()`,
> `get_metadata()`.
> - Reduced use of `maybe_unserialize()` and `is_serialized()`.
>
> The main differences are that the new approach is opt-in and doesn't
> require new table columns.

New description:

 The idea to add a `type` or `format` field to all meta and options tables
 is not new, has been "floating around" for years. The general idea it that
 if some data is (automatically) serialized before saving to the DB, it
 will be (automatically) unserialized after retrieving it based on the
 value of the new field. This will make the `maybe_unserialize()` and
 `is_serialized()` functions pretty much redundant when retrieving data
 from these tables. It will also improve the performance and stability.

 The new field can be very small. Seems that a `TINYINT` (requires only 1
 byte of storage) would work there. Can also be something like
 `VARCHAR(20)` that may eventually prove more useful in the future, but
 perhaps the increase in size would not be worth it.

--

Comment:

 I would strongly recommend using register_meta/register_setting here. This
 requires developers to opt-in to this functionality and we can even add a
 new parameter to other, like `strict` typing, that forces typing.

 Changing the database schema for post meta, user meta, term meta, comment
 meta, site meta, network options and options, is a large database change.
 I will likely break lots of migration scripts and even plugins like
 woocommence do [https://github.com/woocommerce/woocommerce/issues/37762
 raw database queries] on the meta tables.

 I do like the idea of the ticket, skipping serialize could be a massive
 win.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55942#comment:45>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform