variable_get seems to always used $conf array which is fetched a single time. In a long running process where the value of a variable may have changed during operations this causes problems. Is there a simple mechanism in Drupal to tell variable_get to refetch the array from the database rather than using the in-memory variable?
7
-
if you use variable_set() to modify the variable then variable_get() will always give you what you expect.– Scott JoudryCommented Jul 22, 2014 at 15:17
-
@ScottJoudry Not necessarily; it can be overridden in settings.php, and (as the OP is hinting at), can be changed in memory during a single request. ..– Clive ♦Commented Jul 22, 2014 at 15:23
-
What problems are you having? When variable_set() executes, it updates the database, clears the cached config, and then updates the global $conf.– mpdonadio ♦Commented Jul 22, 2014 at 15:36
-
@ScottJoudry the problem is that the process that is doing the variable_get is started BEFORE the variable_set is called. The variable_set updates the database but since the process is already running, the $conf array in memory for that process isn't re-fetched so variable_get always uses the one in memory.– OddibleCommented Jul 22, 2014 at 15:37
-
I can't think of a situation where I would set a variable using variable_set and then use variable_get to retrieve the value I just set. You have the value in a variable already when you run variable_set, why not just use that?– Scott JoudryCommented Jul 22, 2014 at 15:43
|
Show 2 more comments
1 Answer
I don't think Drupal core has anything like that, no. For speed and efficiency, the variables array is in memory pretty much as soon as settings.php has been processed.
You've always got db_query():
$var = db_query('SELECT value FROM {variable} WHERE name = :name', array(':name' => 'var_name'))->fetchField();
$var = unserialize($var);
It would be trivial to build up an efficient variable_get_from_db function based on that.
-
This is the answer I expected, was holding out that something like this was already part of the core.– OddibleCommented Jul 22, 2014 at 15:38
-
Yeah I think you're stuck with something manual to be honest, the variables code is pretty bare bones and there doesn't seem to be anything to cover this use case– Clive ♦Commented Jul 22, 2014 at 15:39
-
This just sounds like a bad usage of
variable get/seta long running application should use astatic local variableor some other custom variable store like it's own DB table for this kind of logic. I dont think blaming the variable api is necessarily right here. I believe the Migrate module does this with its statuses.– tenkenCommented Jul 22, 2014 at 15:42 -
@tenken Agreed, but it's not uncommon for variables to be (rightly or wrongly) used for state in Drupal 7 and lower. D8 has the new state API of course, so makes things a lot cleaner. The big question is whether this variable needs to persist beyond a single page load. If the answer is no, variables are not the answer. But if it's yes, they arguably could be. Although yeah, I'd rather use a session even for that but that's just my opinion...– Clive ♦Commented Jul 22, 2014 at 15:45
-
This is for a situation similar to migrate in that it is a long running process and I just want a persistent variable to cancel it if needed. So periodically it checks an 'am I cancelled' variable and if that returns true I gracefully exit the process. I can set the 'am I cancelled' variable via the admin page for the app. But the process doesn't have its own database table for anything else so setting one up just for a single cancel variable is so overkill, was hoping to use Drupal's existing persistent variable storage but it seems to not have that functionality.– OddibleCommented Jul 22, 2014 at 16:01