[development] don't abuse variabes as storage system (was: low hanging fruit for Drupal 6: variable defaults)

[Gerhard Killesreiter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dries Buytaert schrieb:
> 
> On 04 May 2007, at 00:52, Steven Wittens wrote:
>>> is going to give you the constant instead of the perfectly-valid
>>> assigned value,
>>> isn't it?
>>
>> I think Dries was more trying to illustrate a point. It is trivial to
>> change this so it doesn't suffer from this problem:
>>
>> function variable_get($name) {
>>   $value = db_query(...);
>>   return db_num_rows($value) ? db_result($value) : constant($name);
>> }
>>
>> We've introduced such automatic linking based on naming conventions
>> elsewhere in core too (e.g. menu argument handling, form api
>> callbacks, theme functions, etc), so this idea gets a bit +1 from me.
>> I always liked the idea of centralizing your defaults like this, but I
>> hated that it didn't save you from repeating the defined constant
>> everywhere.
> 
> Unfortunately, as pointed out by Gabor, this solution doesn't fly.  The
> problem is that we have dynamic variables: variable_get($node->type
> ."_something", ...).  A possible solution could be to no longer support
> dynamic variables.  In our running example, we'd then have to add a
> 'something' field to the node_type database table.  However, for a
> number of use-cases this might be impractical.  Then again, it might
> also prevent that people abuse the variables table as an easy storage
> system.
> 

Yeah, that's a major nuissance. Can't we add a "no cache" bit to the
variables table? Variables marked such, would not get added to the
cached version (and bloat it) but would be retrieved from the table each
time when needed. This would be perfectly acceptable for e.g. the
password reminder mail templates.

I imagine it would be ok to set the value of this bit based on the
length of the stored string. We already do something similar for the
locale cache where we do not store strings longer than 75 chars in the
cached version.

The result of this would be:

1) better performance for most pages (the ones that don't require one of
the long strings)

2) somewhat worse performance for a few pages.

3) no guilt trips for abusing the variable_get/set functions once more. :p

Cheers,
	Gerhard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGOzSufg6TFvELooQRAk1AAKDGM4iJeAv3SSQN8i0anR4ZzqxEaACguCsk
qKjxuef3YFPjfMJihVS4ZGw=
=NyLR
-----END PGP SIGNATURE-----