[wp-hackers] Meta tables: Take 5

[scribu]

On Fri, Jul 24, 2009 at 8:03 PM, Otto <otto at ottodestruct.com> wrote:

> On Fri, Jul 24, 2009 at 5:21 AM, scribu<scribu at gmail.com> wrote:
> > - WP core shouldn't create tables that it doesn't use. The same principle
> is
> > applied to bundled javascript and php classes.
>
> I agree with this. However, there's several things that the core could
> be putting into a comment meta table. A lot of the lesser used columns
> could be moved to meta data and this speed up comments retrieval
> (probably by a trivial amount, but hey).


Well, if it was decided that it would be better to move all those columns to
meta, sure.


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!
>


Ok, so let's focus on the API.

First, a function to register new meta types:

register_meta_type($type);


Then we have generalizations of the *_post_meta() functions:

 function add_meta($type, $id, $key, $value, $single);

function update_meta($type, $id, $key, $value, $old_value);

function get_meta($type, $id, $key, $value, $single);

function delete_meta($type, $id, $key, $value);


We need to think how to map these functions:

get_post_custom($id);

get_post_custom_keys($id);

get_post_custom_values($id);


Also, westi proposed functions for manipulating by key:

get_meta_by_key($type, $key);

delete_meta_by_key($type, $key);


But we can go a step further and handle an entire type:

get_meta_by_type($type);

delete_meta_by_type($type);


This is just the first draft, so don't starve the sarlaac yet.


-- 
http://scribu.net