[wp-hackers] How do you store multiple plugin options

[Otto]

Too many posts to reply to. Concatenating responses. Trimming the fat.

On Wed, Mar 24, 2010 at 2:53 PM, Potkanski, Jason
<jpotkanski at tribune.com> wrote:
> More Memory Use (unneeded options potentially being loaded)

Memory use is basically the same, or less. Like you said,
load_all_options loads them up anyway. Array storage is likely more
efficent.

> I really want to see this MySQL easy regex search and replace inside serialized data. Easy and regex never go hand in hand.

I never said anything about regex. If you're having to do regex, then
you're outside the scope of SQL statements to begin with, in which
case you'd have to write PHP regardless.

> You didn't address the database denormalization issue. That's a severe one. If plugin developers are not going to normalize their data, why use the blog options table at all? Use a flat file.

WordPress does not use "normalized" database design in any sense of
the term. IMO, normalization is a crutch for bad development practices
and an excuse to give DBA's too much power that they frankly should
never have been allowed to have in the first place.

> Lets say I want to write a Nagios monitor of a certain DB value of a plugin. In this case I want to monitor the roles of a blog (stored as serialized data) for security reasons. I couldn't just alter a Nagios standard function that can make a simple select call, I would have to write something to pull the data , deserialize it and make sure it is all correct.

Not necessarily. It depends on what you're trying to detect. For
something like that, all you really need to detect is when it changes.
Unless you are concerned about some specific content piece of the
value, of course. If you're wanting to monitor the roles as a whole,
then you're only concerned about changes to them in general instead of
a specific type of change.

> I've written stuff in java that implements serializable. You use this technique with Tomcat to make all server variables of an application stay persistent when the server is restarted. Or when you have multiple tomcat instances and want to share session data properly. You don't use it to dump java objects to the DB.

You're thinking too limited. Serializable can be used anytime you want
to turn a java object (with state information) into a streaming type
of output which can be restored to the object again. And yes, you most
certainly can use this technique to produce, say, a string which you
can store in a database and restore from the database again. I know of
several systems that do things like this.

> I think we can have the best of both worlds. From the easy plugin design perspective, if you just throw an array at set_option or plugin option, it should be able to handle storing those options automatically. From my database normalization perspective, the set_option functions probably shouldn't use the serialize/deserialize methods if it can be avoided.

If set_option and get_option didn't implement serialize automatically,
it would be necessary to do it yourself, to avoid putting multiple
options into the database. In other words, your "database
normalization" is the very thing that I consider undesirable in the
first place.

See, you seem to think that having 10 rows for 10 options is a good
thing. I say that if I always need all of those 10 options together,
then I should have them all together and in only 1 row of the
database. I don't need "1 option" at most places, I need all 10
options at most places.

Think about it, when do most plugins need options?
- At their settings screens, where they are displaying/changing those
options all at once.
- When they produce their output, which means that the options are
needed to produce said output. And usually, you need all of them to
produce that output. Or, if not all, then most of them. It's a very,
very rare case where I only need 1 or 2 of my plugin options in a
single page generation.

On Wed, Mar 24, 2010 at 3:21 PM, Mike Schinkel
<mikeschinkel at newclarity.net> wrote:
> So does WordPress do maybe_unserialize() everywhere it unserializes to ensure the errors are suppressed?

Yes, get_option calls it.

> My takeaway is that it's an acceptable hack at time while at other times it can result in data of actual data.  For example, if I wanted to change one but not all similar values in a complex option I could easily overwrite other data that I hadn't intended to overwrite.

That would be a plugin programming error though, not a user error. And
it's one that is easy enough to avoid.

> So all options in one array, though having numerous benefits, are not a panacea and are not appropriate in all cases.

Not in all cases, no. Nothing is ever appropriate in "all" cases.

However, in *most* cases it's the best way to do it.


On Wed, Mar 24, 2010 at 3:24 PM, Potkanski, Jason
<jpotkanski at tribune.com> wrote:
> wp_load_options() bulk loads all these options with one DB call. Most of the time the get_option is going to hit the memory cache.

Loading 10 rows of data takes more time than loading 1 row with the
same data. Seriously, it's a measurable amount.

> Not sure if you need the separate table.
>
> I would propose the a new define "WP_NORMALIZE_DB" or some such which would use different version of the get/update/set_option functions that wouldn't serialize the data. It would probably require an addition to the schema options table of a 'child' column so that it relates to a master option.

Negative. That would make plugin programming far more complex, as now
it would have to account for both cases and do it's own
(un)serialization when the user had enabled that. Very bad way to do
things.

-Otto