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 customisable). 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 overrides. 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 comment 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 default.? 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