[development] Variables, lookups, and memory usage

Allie Micka allie at pajunas.com
Thu Dec 15 18:24:56 UTC 2005

Hey folks,

I've written a lookup module to store and manage generic name/value  
pairs, organized by "realms".  For example:

REALM     NAME         VALUE
state     MN           Minnesota
state     TX           Texas
country   US           United States

The basic premise is to keep this type of data in one place, rather  
than all over the map (e.g. a states table for ecommerce, a states  
table for something else, so-on.)  With the lookup API, any module  
can stash/get its codes in the table, and it supports importing from  
a text file.  I got used to working this way at my last job (a big  
Oracle shop - I think this model is called "one true lookup table")

I'm considering using this for module settings to save memory.  Some  
of my modules (e.g. send) have lots of settings for email templates,  
default message text, etc.  It's silly to shove all of this into the  
variables table and haul it around on each page request, when 1 out  
of 5,000 page views will actually require it.

So, I'd add:

REALM     NAME         VALUE
send      template     <html><body>...
send      message      Here's some content from ...

I still have a consistent place to stash these settings ( lookup_set 
() , lookup_get() ), but I only pull them as needed.  An overall  
memory savings, and handy as well.

The lookup_get() is functionally similar to the variable_get()  
function, except that it requires a $realm parameter:

   lookup_get($realm, $name=null);  // without a name, it returns a  
keyed array of the whole realm

My Questions:

   1) There's potential overlap with variables and probably other  
stuff too.  Is there a better way?
   2) Is it weird to create a confusing-sounding component module  
like this and require it for other modules?  Should this (or a  
derivative of this) functionality be available in core instead?

Allie Micka
pajunas interactive, inc.

scalable web hosting and open source strategies

More information about the development mailing list