My point was the most important thing is the API – if we get that wrong it’s much harder to change.

Making incremental changes to the db structure to optimise it when issues arise is much easier that fixing a broken API

I don’t have any specific examples – but the aim would be to ensure that plugins can avoid direct queries.

I would like to know what you had in mind with $search_type in

get_meta_values(‘cron’, $search_value, $search_type);

While in general I agree with you, strict adherence to your words could paint us into a nasty corner. Let me use an example: The API could be implemented to store all meta for a post as a serialized array in the wp_posts table. Doing so would adhere to your “table structure doesn’t matter” ideal but would be disastrous for enabling additional functionality. If meta was implemented in that manner it would be effectively impossible to implement a performant filter on a list of posts for a given meta key/value pair because every record would have to be tested via PHP instead of pushing to SQL in a WHERE clause.

This is the exact problem I had with NexGen Gallery in that it used serialized arrays instead of a proper linking table. In order to implement functionality required by my client I had to modify the code for that plugin.

So yes, ideally a good API should be all that matters but in reality the table structure does matter.

@scribu: Is what the plugin does really not possible we the post meta key / value stuff built into WP_Query e.g. – https://core.trac.wordpress.org/ticket/7431 and https://core.trac.wordpress.org/browser/trunk/wp-includes/query.php#L2140

No, because it has to check for more than one key-value pair.

We should strive to provide a good enough api so that plugins don’t have to use direct SQL queries.

Completely agree.

We try very hard to maintain apis we are not interested in maintaining table structures just to not break plugins.

I know, but why break plugins unnecessarily?

Anyway, I’m glad we agree that plugins shouldn’t have to deal with creating meta tables, no matter the type.

Yes. There will always be cases which are the exception that breaks the rule.

We should strive to provide a good enough api so that plugins don’t have to use direct SQL queries.

We try very hard to maintain apis we are not interested in maintaining table structures just to not break plugins.

I assume that other plugins that would be relying on comment meta, for example, would need similar functionality.

If people need different ways of accessing the data then we should add API calls for it – plugins shouldn’t need to use raw SQL queries to achieve things as then we lose the benefits that caching can provide.

If we have multi-table we are likely to end up with a lot of similar looking tables, if we have single table we will need an extra column for the type of meta – the only choice between the two is going to be performance.

In both cases we should be able to write an api which means that plugins don’t do raw SQL queries – that way we could make it possible for people to use either approach depending on there scaling needs. But that’s all implementation detail

get_meta_value( ‘post’, ‘post_custom_field_name’, 123 );

putting the meta_type_id last would allow you to make it optional easily, so that for something like your example (cron) where you might not have a numeric id that makes sense, it could be automatically handled (or completely ignored) internally. That would allow you to index the tables on that value, speeding up lookups a lot (since if we stick all meta in one big table, it’s going to get pretty big, pretty quickly).