[development] DEP - cascading variable system

Adrian Rossouw adrian at bryght.com
Wed Nov 30 17:53:35 UTC 2005

On 30 Nov 2005, at 7:36 PM, Chris Johnson wrote:

> Moshe Weitzman wrote:
>> about #4. I'd like for user variables to be loaded into the $user  
>> object  so that we don't go to the DB for them multiple times on a  
>> page view. For example, lets say we invent a user pref called  
>> 'show signatures' and I set that to FALSE because I am on a low  
>> bandwidth connection. I would not want a variable_get('show  
>> signatures') to hit the DB every time we show a node or comment.  
>> maybe a static cache would solve this.
> Umm, doesn't variable_get() only hit the database the _first_ time  
> the variable is requested on a page?  After that, it's in the  
> global $conf, isn't it?
> In general, I think it makes sense to keep user variables in user- 
> related tables, *not* in the {variables} table.

This is only for places where we want to override the defaults  
specified by the system.

Like for instance whether or not to display tinymce, the user's  
frontpage (if that's customisable), the user's theme (if that's  
So that every time we want to use (say) the site_frontpage variable,  
we don't have to explicitly code and check for the different kinds of  

We could put the user's variables in the user table,  and  
variable_get needs to know how to check variables for different domains.

I don't like the 'data' field. It's great if you are doing fast  
development, but what happens when (in recent memory), we disable  
paging on drupal.org, and the interface element to configure that has  
been removed. You'd need to open up every user object and unset that,
and then save it back to the database. With that in the variables  
table, it would be a single line of sql.

SO what happens when you stop a theme that some people had as a  

With these variables (not properties) in the variables table, we can  
control stuff like this.

Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com

More information about the development mailing list