[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
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
More information about the development
mailing list