[wp-hackers] Rebuttal (re: Meta tables: Take 5)

[mikeschinkel at newclarity.net]

+10 Best approach yet.

One thing to consider; in the "standard" approach would it make sense  
to have meta type stored in it's own table so that the type field in  
the meta table could be an INT and thus stored and indexed efficiently?

Sent from my iPhone

On Jul 24, 2009, at 1:24 PM, Jared Bangs <jaredbangs at gmail.com> wrote:

> On Fri, Jul 24, 2009 at 8:46 AM, Peter Westwood
> <peter.westwood at ftwr.co.uk>wrote:
>
>>
>> Agreed
>>
>> I was very careful in my proposal [1] to talk about an api which  
>> was db
>> structure agnostic, because they may be arguments both ways and I  
>> think the
>> storage mechanism should be completely separate from the api and it  
>> is
>> really the api we need to decide on first!
>>
>> Once we have actually got some data about what is being stored and  
>> what is
>> being queried there may be cases when a object type specific meta  
>> table is
>> required but I would expect that for 80% of use cases a single  
>> table would
>> be fine.
>>
>> For what its worth bbPress is built around a single meta table [2]  
>> (which
>> even the options go in)
>>
>> westi
>>
>> [1]
>> http://blog.ftwr.co.uk/archives/2009/07/23/a-better-meta-api-for-wordpress/
>> [2]
>> http://trac.bbpress.org/browser/trunk/bb-admin/includes/defaults.bb- 
>> schema.php#L2<http://trac.bbpress.org/browser/trunk/bb-admin/includes/defaults.bb-schema.php#L28 
>> >
>
>
> +1 vote for implementing sooner rather than later, using the API  
> Peter laid
> out. Sounds like everyone can agree on that point, and I think he's  
> correct
> in saying that's what matters for consistency and ease of use for  
> plugin
> authors.
>
> The single-table / multi-table decision is an implementation detail  
> behind
> the API, and one which almost everyone using the API (active  
> participants on
> this list topic excluded, of course) would have no strong opinion on  
> either
> way, and should never have to know or care about until it becomes an  
> issue
> for them.
>
> On that point, it seems like a single table approach would be the  
> simplest
> and would adequately address the needs of the vast majority of the  
> blogs out
> there, while avoiding the extra complexity for the cases where it  
> isn't
> needed.
>
> So I'd say put that in the core (at least initially), and put enough  
> hooks
> in so that people running sites that somehow justify the split table
> approach can change out the storage code behind those API calls  
> without
> affecting all the plugins that are using the API. Someone who really  
> needed
> the multiple tables could then pretty easily whip up a plugin to do  
> this,
> including migrating all the stuff from the single table upon  
> activation.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers