Store bbPress options in single row

[mordauk]

Right now there are 50+ options registered in the database as individual options, all of them autoloaded.

Most of the options are single value rows, such _bbp_forums_per_page = 50.

Has it been considered to put all of the main options into an array stored in a single option?

[johnjamesjacoby]

It has actually.

Storing them in a serialized array provides no performance benefit, complicates the code, and could actually harm performance in the long run. Here's how:

• WordPress's options autoloader is already optimized for slurping all options into a cached array. It's hard to beat the performance and simplicity of an indexed key/value table.
• We are currently able to use WordPress's API for getting any individual option we want, without the need for custom bbPress functions just to retrieve settings. Having our own array would require a custom set of methods to cherry pick keys and values from it.
• BuddyPress previously used this method, and we're slowly trying to remove our dependency on it. Adding/removing support for deprecated settings is a bit of a pain this way.

The only thing I think we'd gain would be an ability to use magic methods to help with deprecation, but it's actually quite easy to do with filters on the options API currently.

There are differing opinions on what's the best etiquette here, and I'm of the opinion that the simplicity of storing them conventionally outweighs the cost of muddying up the options table a bit.

Happy to keep the discussion going here though!

[mordauk]

Completely missed your answer, oops.

I'm looking on my options table on easydigitaldownloads.com and there are currently 67 rows in the table just from bbPress options. Most of the options have very simple values, such as 1 or 0.

I'll be the first to admit that I know much less about SQL performance than many others, but I'm failing to see how storing them all separately is faster than storing them in one array in one row.

Whether it's in one array or two, the options are still going to get slurped into the cached array by WP core. The only difference is that instead of an option being retrieve from $options[ $key ] it would be from $options[ 'bbpress'][ $key ].

The advantage, however, is that there is only 1 row autoloaded for all of bbPress instead of 67.

Am I missing an element here?

[johnjamesjacoby]

MySQL will handle either case totally fine. I'm thinking about two other cases:

• Individual options are much easier to edit than a serialized array.
• The added overhead & complexity of new & custom PHP functions to traverse another nonstandard array to check for each option.

In this instance, I'm more comfortable sticking to the simple convention we already know and are accustomed to, compared to inventing another layer of abstraction for foo = bar;