[wp-hackers] Meta tables: Take 5

[Mike Schinkel]

On Aug 5, 2009, at 4:38 AM, Ozh wrote:
> To me the main & valid argument against ENUM is that, as stated in the
> original ticket [1], it gives much more flexibility to plugins which
> can create arbitrary values without modifying core table structure.

"Modifying core table structure" is not of itself an evil, at least  
not that I'm aware of.

> Like, I could make a plugin that would deal with new post status like
> "ozh" without having to ALTER everything beforehand.

If requiring plugin developers to know SQL is a concern it can of  
course be encapsulated into a register_meta() function.

If lockdown of databases is the concern, I understand that a bit  
although I would posit that not supporting table modification will  
become less realistic with the need for custom post types when  
functionality like Pods[1] becomes as common with WordPress  
installations as CCK is for Drupal installations.

And if it's simply a convenience to not need to register_meta('ozh')  
then I would ask if coding that only implies the existence of a new  
type of post status is really a best practice?

That said, the other option I proposed is to create a wp_meta table  
and ignore ENUMs. No comments on that?

On Aug 5, 2009, at 9:16 AM, Otto wrote:
> On Tue, Aug 4, 2009 at 5:06 PM, Mike
> Schinkel<mikeschinkel at newclarity.net> wrote:
>> Note that Otto said it was a very bad idea, but was overruled by  
>> Matt.
> Yeah. I was wrong. It's way more flexible, and I don't see scaling as
> a major issue there.

There has been a lot of pushback in the list related to combining all  
metadata into a single table for performance scalability reasons  
though I don't know if you were one of those doing the pushback on  
that issue or not.  Using ENUM or SMALLINT vs. VARCHAR(20) for keys  
would significantly reduce that concern if not eliminate it.

-Mike Schinkel
WordPress Custom Plugins
http://mikeschinkel.com/custom-wordpress-plugins/

[1] http://pods.uproot.us/