variable api vs custom table

Question

I have a module Block No Results which displays the no results data when block has no results. Variable Api if I will use the variable api then I need the 4 variables for a single block to keep the no results data and displays the results. Custom Table If I'll go with custom table then I'll keep the 6 fields in the table.

id - primary key

module - varchar(64)

delta - varchar(32)

status - tinyint(4)

content - longblob

empty_criteria - varchar

UNIQUE KEY md (module,delta)

KEY list (status,module)

Overview On every block view I need to check that whether the block no results criteria is enabled for this block.If it is then I need to check what is the empty criteria and on the basis of that I need to perform action.

Problem Variable api : If I'll use the variable api then on each block view I need to load the variables separately i.e. 5 variables load( ~5 database fetch queries)(if block no results is enabled) and 1 variable load(~1 query)(if block no results is disabled for that block). As the variable api is integrated with the cache api so on the development sites usually get the results from cache.This seems to me not good approach in the case if a site has 100's of blocks.

Custom table Load the whole row using the module & delta and take the appropriate action if needed.

Currently I have implemented this using the variable api. Which approach should I use ? Is there any other better approach then these ? how I can make it more better if you are going to suggest an approach ?

Answer 1

Not an answer per say; more of a critique of some of your assumptions with variables.

If I'll use the variable api then on each block view I need to load the variables separately i.e. 5 variables load( ~5 database fetch queries)(if block no results is enabled) and 1 variable load(~1 query)(if block no results is disabled for that block)

In actuality all variables get loaded on EVERY pageload with a single query, including cache_page hits (think anonymous users) unless your doing something special ($conf['page_cache_without_database'] = TRUE;, varnish, or boost). variable_initialize() get's called very early; dig though drupal_bootstrap() a little bit to see. So a variable get doesn't cost you a db query, but it's not a good idea to abuse the variables db table because the more data that's in there (KB), the slower Drupal gets.

Actual answer:
My personal preference is to use cache_get_multiple() if your looking at 100s of items to get; unfortunately it looks like _block_render_blocks() makes this hard to do; the function that calls hook_block_view_alter(). So in this case a cache_get would be the easiest way to go. Another option is a cache loader; all in one cid (harder to manage writes) or get all cid's for the enabled blocks block_page_build() or $blocks = drupal_static('block_list'); with drupal_static(). What's ideal depends on many factors, biggest one being how large (KB) is the cached data; if its small a loader & drupal_static() might be the fastest option. If you have a large amount of data then doing individual cache_get() call might be better due to the lower memory usage and not loading unused data. See https://www.lullabot.com/blog/article/beginners-guide-caching-data-drupal-7 for more details on caching.

Also be aware of cores built in block caching. Use it if at all possible. See https://www.drupal.org/project/blockcache_alter for ideas and usage.

Answer 2

I would suggest using a custom table in combination with the CTools module. This has the additional benefit of making your configuration exportable with the Features module.

There is some pretty good documentation online, and if you install the Advanced Help module along with the CTools module, you'll get some pretty good documentation as well.

EDIT: CTools also caches your configuration objects for you, which means less code to write yourself.