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

[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.1
Component:  Database                      |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-unit-tests needs-patch  |     Focuses:
------------------------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:3 barry.hughes]:

 > {{{
 > `type` ENUM( 'int', 'float', 'string', 'bool', 'php', 'json' )
 > }}}
 >
 > In the above example, we have four scalar types and two serialization
 types—PHP (default/what we use today) and JSON. Introducing JSON as a
 supported serialization method:

 I'm a bit "uneasy" specifying "json" as type in that way. Thinking the
 ENUM should stick to the PHP's primitive types, and use PHP's
 `serialize()` for encoding (same as currently).

 If a plugin wants to use JSON, it would be pretty easy to encode the value
 before passing it to the API. Then the plugins will "know" to decode it
 after retrieving it. Support for both encoding methods may be nice, but
 don't see a good way to add it without adding another field to the table.

 Looking at `gettype()`
 (https://www.php.net/manual/en/function.gettype.php) there are 10 possible
 return values:
 - "boolean"
 - "integer"
 - "double" (the old name of "float"; best to use `float` here imho)
 - "string"
 - "array"
 - "object"
 - "resource"
 - "resource (closed)" as of PHP 7.2.0
 - "NULL"
 - "unknown type"

 Thinking that the default value for the ENUM should be "unknown type".
 This will signify that we will need to run `maybe_unserialize()` on the
 data (back-compat). Can probably be named just "unknown". Was thinking it
 can probably use the empty string there, but that would make it somewhat
 unclear when looking at the DB.

 Wondering if `NULL` (the PHP type) should map to `"NULL"` in the ENUM.
 Seems logical but might run into some problems later on, perhaps?

 Thinking this shouldn't support "resource" and "resource (closed)".
 Currently not supported afaik, and not sure it's a good idea to save a PHP
 resource in the DB (not even sure how/if that can still be used somehow
 after retrieving it).

 The rest are pretty self-explanatory. Array and Object will be serialized,
 the others can be typecast when retrieving, or it can use `settype()`
 (https://www.php.net/manual/en/function.settype.php).

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