[wp-hackers] Metadata Mess

[Jacob Santos]

So what you are saying is that I could have 5+ or worse case 20+ meta 
tables that all have similar structure. Hmm, I think views would fix 
some problems yes.

It is nice that there is at least some API for the new metadata, so that 
it can eventually be ported to a single table.

Jacob Santos

Peter Westwood wrote:
>
> On 22 Dec 2009, at 11:41, Malaiac wrote:
>
>> 2009/12/22 Jacob Santos <wordpress at santosj.name>:
>>> id,
>>> object_type
>>> object_id
>>> key_name
>>> key_value
>>>
>>> Could easily replace the 3 tables that currently exist. Of course, 
>>> it might
>>> seem slow that object_type would be varchar and usually a number 
>>> index will
>>> be faster, but at this point, I'll rather go with anything.
>
> The current solution is scalable enough to support meta against any 
> object type and the low level function do just that to allow a plugin 
> to add a different sort of meta.
>
> Migrating all the current meta into one table would cause an upgrade 
> headache for sites which make a lot of use of the current postmeta and 
> commentmeta tables migrating all that data would take time.
>
> It would also break all plugins that did interesting things with meta 
> using direct queries because they stored interesting data there.
>
>>
>> if we're going in that direction, _PLEASE_ make object_type an ENUM
>> and not a VARCHAR. People who are going to use new objects types are
>> fluent enough to ALTER the ENUM.
>
>
> We don't use ENUM because it reduces DB portability as it is not a 
> standard SQL datatype.
>
> We specifically switched away from it to make it easier for people to 
> write drop in replacements for wpdb which use other databases.
>
> Cheers