mark.wordpress at txfx.net
Fri Apr 14 05:59:27 GMT 2006
On Apr 13, 2006, at 5:39 PM, Stewart Ugelow wrote:
> Just out of curiousity: why create an entirely new table?
The main reason is backwards compatibility for plugin authors. Not
all post meta interaction possibilities are covered by API functions,
and require direct queries. For instance:
- selecting all post ids that have a certain meta key or key/value combo
- deleting based on key/value (not knowing the IDs)
- updating based on key/value
If this table also contained comment meta, all these queries would
have to be changed by the plugin authors. My initial involvement
with WordPress was as a plugin developer... so I tend to try and
think from that point of view when writing core patches.
> So what happens if you have your two coolers of beer and soda and then
> your friend shows up at your party with a case of iced tea?
> You have to file a trac ticket asking Matt or Ryan for permission to
> buy another cooler, everyone at the party gets to comment about
> whether iced tea is an essential beverage to the party core, and you
> have to write a whole new set of instructions on where the iced tea is
> located and what the process is for grabbing one if you want one. Then
> those instructions have to be maintained and updated every time you
> throw a party going forward.
The idea of a generic "data" table has been floated before... some
people are sticking huge things in options table. The feeds really
don't belong there, for example. But still, the cooler analogy
applies... just create a "generic" cooler for everything that isn't
beer or soda... wp_data or something like that. And of course,
plugins are free to (and many do) create their own tables. For big
things that need to store, sort, query, update lots of data, that
would be the prudent thing to do.
My post meta table is huge... tens of thousands of entries... that's
getting to the point where non-indexed queries are going to kill
performance, so sticking an extra WHERE condition on there is going
to slow things down (remember, that query gets run on every WP view
that returns posts!). And regardless... the backwards compatibility
issue still applies, which was my main reason. I don't like breaking
things unless there's a really good reason to do so.
More information about the wp-hackers