[wp-hackers] Meta tables: Take 5
mikeschinkel at newclarity.net
Wed Aug 5 16:13:54 UTC 2009
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 , 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 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
> 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.
WordPress Custom Plugins
More information about the wp-hackers