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

[Jared Bangs]

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.