[wp-hackers] Storing Arbitrary Data as Custom Post Types

[Chris Scott]

On Wed, Dec 9, 2009 at 3:02 PM, Dougal Campbell <dougal at gunters.org> wrote:
> On Dec 9 2009 1:43 PM, Otto wrote:
>>
>> On Wed, Dec 9, 2009 at 10:19 AM, Dougal Campbell<dougal at gunters.org>
>>  wrote:
>>
>>>
>>> In a nutshell, my proposal was going to be that we use a naming
>>> convention
>>> like: [area]:[slug]:[name]
>>>
>>> For example, if you had a plugin named "Tweet Fu" (which has the slug
>>> 'tweet-fu' in the respository), you might have an option named:
>>> plugin:tweet-fu:last_tweet_timestamp
>>>
>>> Or if you have a theme that saves its own option:
>>> theme:my-theme-name:header_image_filename
>>>
>>
>> Generally speaking, most plugins should be using a single option
>> holding an array of their settings. I tend to go with
>> pluginname-options, personally.
>>
>> Any "standard" should take this into account, as keeping every option
>> in a separate row can be bad practice.
>>
>
> I think part of the reason that consolidating multiple options into a single
> array is considered best-practice now, is *because of* the current state of
> option chaos. That, and the fact that you don't have to make 10 separate db
> calls to get 10 different options. But if the options were namespaced
> consistently you could just SELECT ... WHERE option_name LIKE
> 'plugin:foo-plug:%' and get all your info in one call anyways.
>
> Regardless, even if everyone used an array for all options (which is fine
> for probably 99% of the plugins out there), the namespacing idea would still
> make it easier to make sense of things in those rare cases when you have to
> dive directly into the table for some reason.
>
> Again, I'm not sure whether or not its an idea worth trying to champion. But
> at the least, I figure it's at least worth seeing if some more solid
> best-practices could be extracted from the discussion. Currently (AFAIK),
> the extent of best-practices around saving options is "store all values
> together in an array whenever possible" and "prefix your option name", with
> little guidance as to a prefix format.
>
> Do we *need* to define a suggested prefix format? I dunno -- maybe it's
> overkill. There's no easy way to enforce it without making changes to core
> (though I have some ideas about that). Would a consistent prefix format be
> useful? That's what I'd like us to discuss.

Something to throw into the mix for using options for storage is that
if they are set to autoload, then the entire array of autoloaded
options are put into one cache object. Using memcached means you are
limited to a bit under 1MB for all your autoloaded options and the
same for any single non-autoloaded option since they are cached
individually.

--
Chris Scott
http://iamzed.com/
http://hailtheale.com/

>
> --
> Dougal Campbell <dougal at gunters.org>
> http://dougal.gunters.org/
> http://twitter.com/dougal
> http://twitual.com/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>