[wp-trac] [WordPress Trac] #55942: Add a "type" field to the meta and options tables

WordPress Trac noreply at wordpress.org
Wed Apr 12 21:54:48 UTC 2023


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

Comment (by azaozz):

 (Finally) was able to spend more time on this. Went through all needed
 changed back and forth couple of times. Backwards compatibility is really
 "tough" here, not just for the code but for the current vs. updated
 behavior too.

 Unfortunately seems there's no good, straightforward way to implement this
 as a "progressive enhancement". The only possibility seems to be to add
 another param to `update_option()` and `update_metadata()` to indicate
 strict value types. This will still require changes to the caching which
 might bring problems if a plugin tries to access the cache buckets
 directly.

 The worse part is that it would "split" `get_option()` and
 `get_metadata()` return values in two groups:
 1. "Old" values that don't have proper types that were added or updated
 before this was implemented or saved without `strict` types.
 2. "New" values that have correct types that were added or updated with
 `strict` types.

 That seems confusing.

 Also tested with adding "strict types" param to `get_option()` and
 `get_metadata()`, however that makes them even more unpredictable. Old
 values cannot be returned with proper types as that data will not be in
 the DB.

 So thinking the best way to implement this would be to add another
 optional param to `get_option()` and `get_metadata()` (and similar) with
 the expected value type. That should be 100% backwards compatible and will
 still ensure values with the proper types are returned (when expected) and
 reduce calls to `maybe_unserialize()`, etc. This also means no need for
 new columns in the meta and options tables.

 Patch coming up.

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


More information about the wp-trac mailing list