[wp-hackers] geocomments?

[Mark Jaquith]

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.

--
Mark Jaquith
http://txfx.net/