We should not call API functions in the update process, but for some reason this has not been applied to variable_set() - it does not invoke hooks, but it is also a function that is likely to be completely removed once things are converted to CMI.

Since that is going to happen after some updates have already run moving things to the variables table - i.e. various D8MI patches as things stand, we should add update_8000_variable_set() to 8.x. This way when the function is removed, those updates will still run OK.

Critical bug because we already have some updates that do this.

Files: 
CommentFileSizeAuthor
#30 update-variable-functions-1348162-30.patch13.89 KBBerdir
PASSED: [[SimpleTest]]: [MySQL] 39,804 pass(es). View
#30 update-variable-functions-1348162-30-interdiff.txt554 bytesBerdir
#28 drupal8.update-variable.28.patch13.54 KBsun
FAILED: [[SimpleTest]]: [MySQL] 39,740 pass(es), 12 fail(s), and 2 exception(s). View
#23 drupal8.update-variable.23.patch12.09 KBsun
FAILED: [[SimpleTest]]: [MySQL] 39,737 pass(es), 12 fail(s), and 2 exception(s). View
#17 variable_update.patch2.53 KBcatch
PASSED: [[SimpleTest]]: [MySQL] 35,114 pass(es). View
#15 variable_update.patch2.94 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: failed to enable simpletest module. View
#13 variable_update.patch3.41 KBcatch
FAILED: [[SimpleTest]]: [MySQL] 35,000 pass(es), 8 fail(s), and 14 exception(s). View
#10 variable_update.patch3.41 KBcatch
FAILED: [[SimpleTest]]: [MySQL] 34,989 pass(es), 12 fail(s), and 14 exception(s). View
#4 variable_update.patch3.41 KBcatch
FAILED: [[SimpleTest]]: [MySQL] 34,348 pass(es), 4 fail(s), and 0 exception(es). View
#1 update_variable.patch4.44 KBcatch
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View

Comments

catch’s picture

Status: Active » Needs review
FileSize
4.44 KB
FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. View

Untested patch.

I renamed update_module_enable to update_module_enable_0 - it does not make sense to call that function update_module_enable_8000 because that would match the system module schema from 8000 onwards, not prior to that update, so 0 is all we have really.

Status: Needs review » Needs work

The last submitted patch, update_variable.patch, failed testing.

catch’s picture

Title: Add update_****_variable_set() » Add update_****_variable_*()
Category: bug » task

Nothing is broken yet so more rightly a task.

catch’s picture

Status: Needs work » Needs review
FileSize
3.41 KB
FAILED: [[SimpleTest]]: [MySQL] 34,348 pass(es), 4 fail(s), and 0 exception(es). View

This should fix the install issue at least.

sun’s picture

Title: Add update_****_variable_*() » Add update_variable_*()

I can see the point of update_variable_get|set|del(), but the version suffix and so on looks like premature optimization for CMI, which feels a bit designed into the blue right now, as we don't know 1) whether CMI will make it and 2) whether we'll actually need a version suffix then.

Thus, I'd like to remove that version suffix.

In the end, this is still questionable though. There's an issue somewhere which basically attempts to solve this from the opposite direction: Resetting module_list() to nothing before invoking a module update function. Thus, same effect; no hooks can be called. Overall, that sounds like a better approach to me, as we're basically duplicating the entire effin' system in update.inc meanwhile...

catch’s picture

Resetting module_list() only solves a part of this, it's about schema changes as well.

Whether or not CMI gets in or not, say we changed the schema of the variables table in system_update_8010(). Now you need to rename update_variable_*() to update_variable_*_0() and introduce update_variable_*_8010().

If contrib modules are already updating to 8.x and using update_variable_*() they need to switch to update_variable_*_0() - but that porting could happen at any time in the next two years, at which point the only record of which function to use is the date of the commit. Whereas if we add the suffix now, those existing updates don't need to be changed. If we never change the variable schema again then it's just an extra digit - it's like putting out a 1.0 release before 1.1.

Status: Needs review » Needs work

The last submitted patch, variable_update.patch, failed testing.

Gábor Hojtsy’s picture

Ok, so we don't yet have an API change in variable_set/get and we will likely not have any, since the functions are going away in Drupal 8, right? So regardless of the introduction of their update counterparts, they will not be useable in update functions in D8. Sounds like it will be really a question of the upgrade path of CMI, whether it leaves the variable data lingering for other update functions to run, whether the CMI update will run in early bootstrap and later update functions will need to use its new data source (and replicate those future methods/functions). To me it looks like that is the point when the variable API actually gets a change and at that point, the data source might be very different, so this would need to be revisited entirely, no?

catch’s picture

If we have the {variable} table, we can write helper functions that query it.

If the {variable} table gets removed at some point (seems more likely we'd leave it in for contrib until Drupal 9 but you never know), then those helper functions will still work, because they will be running in updates prior to the one that removes it.

So either way we can add these now, and know that they'll work going forward regardless of other changes (except for a full migrate API-based upgrade path - but if we have that then we can largely stop worrying about issues like this).

catch’s picture

FileSize
3.41 KB
FAILED: [[SimpleTest]]: [MySQL] 34,989 pass(es), 12 fail(s), and 14 exception(s). View

Re-rolled.

catch’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, variable_update.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
3.41 KB
FAILED: [[SimpleTest]]: [MySQL] 35,000 pass(es), 8 fail(s), and 14 exception(s). View

Status: Needs review » Needs work

The last submitted patch, variable_update.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
2.94 KB
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: failed to enable simpletest module. View

The update_module_enable/update_module_enable_0 change is failing somewhere. That can go in a new issue so this one just adds the new function.

There's lots of updates using variable_get()/variable_set() already in Drupal 8, those need to be updated but that's possibly a novice task if this patch passes.

The update system itself uses variable_get()/variable_set(), that will likely need to change to the key/value store when that's landed, but that's using variable_get/set as an API so we can't switch it here (i.e. it needs to use actual API calls and we'll need to have that API available before running the Drupal 8 upgrade, or completely refactor how the upgrade path works such as moving to migrate).

Status: Needs review » Needs work

The last submitted patch, variable_update.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
FileSize
2.53 KB
PASSED: [[SimpleTest]]: [MySQL] 35,114 pass(es). View

Without .htaccess cruft.

effulgentsia’s picture

Status: Needs review » Needs work

I think it makes sense to do this, given that we know we'll likely want to remove the variable_*() functions, so let's be nice to contrib maintainers who port their modules early.

There's lots of updates using variable_get()/variable_set() already in Drupal 8, those need to be updated but that's possibly a novice task if this patch passes.

Not that many: block, language, locale, node, and system modules. Now that the patch passes, should they be included in this initial patch, or deferred until this initial patch lands?

+++ b/core/includes/update.inc
@@ -285,6 +285,62 @@ function update_module_enable(array $modules) {
+  $GLOBALS['conf'][$name] = $value;

Why are we updating this global, but not also calling cache('bootstrap')->delete('variables')?

Gabor/sun: do your concerns still stand, or are catch's answers satisfactory?

tim.plunkett’s picture

Bumping to get back on everyone's radar. Is this still necessary, and if so, should it be postponed on all of the variable-to-config conversions?

aspilicious’s picture

I don't think it needs to be postponed. We just have to get this in (without any conversions) and when all the variable conversions are done we can see what needs to be done. Or we can add the few cases mentioned in #18 that needs updates anyway.

catch’s picture

There's no need to postpone this, lots of updates are using variable_get()/set() already that shouldn't be.

heyrocker’s picture

Issue tags: +Configuration system

Tagging.

sun’s picture

Priority: Critical » Major
Status: Needs work » Needs review
Issue tags: +API addition
FileSize
12.09 KB
FAILED: [[SimpleTest]]: [MySQL] 39,737 pass(es), 12 fail(s), and 2 exception(s). View

- There won't be a version 1 of the {variable} schema, so the schema suffix in the update_variable_*() functions is needless.

- Setting new variable values on global $conf is pointless, since updates are executed in a batch. Everything that depends on variables during the upgrade should use the update_variable_*() replacements in the first place.

- Fixed phpDocs and coding style.

- Converted all existing variable_*() calls in D7->D8 updates throughout core.

Status: Needs review » Needs work
Issue tags: -API addition, -D8 upgrade path, -Configuration system

The last submitted patch, drupal8.update-variable.23.patch, failed testing.

sun’s picture

Status: Needs work » Needs review

#23: drupal8.update-variable.23.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +API addition, +D8 upgrade path, +Configuration system

The last submitted patch, drupal8.update-variable.23.patch, failed testing.

catch’s picture

Setting new variable values on global $conf is pointless, since updates are executed in a batch.

Depends how they're run surely?

sun’s picture

Status: Needs work » Needs review
FileSize
13.54 KB
FAILED: [[SimpleTest]]: [MySQL] 39,740 pass(es), 12 fail(s), and 2 exception(s). View

Sure. But that means that the global $conf will be different, depending on how you run updates. I can't speak for others, but I don't want to support that. We have enough conditions and varying scenarios in the upgrade path already, I don't need yet another.

Fixed the LanguageUpgradePathTest.

Status: Needs review » Needs work

The last submitted patch, drupal8.update-variable.28.patch, failed testing.

Berdir’s picture

Status: Needs work » Needs review
FileSize
554 bytes
13.89 KB
PASSED: [[SimpleTest]]: [MySQL] 39,804 pass(es). View

Replaced another variable_get() in locale.install, this seems to work for me now.

sun’s picture

Status: Needs review » Reviewed & tested by the community

Excellent! Thanks @Berdir for figuring out that last glitch!

Dries’s picture

This works for me. Committed to 8.x. Thanks all.

Dries’s picture

Status: Reviewed & tested by the community » Fixed
Berdir’s picture

Title: Add update_variable_*() » Change notification for: Add update_variable_*()
Priority: Major » Critical
Status: Fixed » Active

I think this needs a change notice, should be easy enough to create.

xjm’s picture

Berdir’s picture

Status: Active » Needs review

Something like this: http://drupal.org/node/1721608?

tim.plunkett’s picture

Title: Change notification for: Add update_variable_*() » Add update_variable_*()
Priority: Critical » Major
Status: Needs review » Fixed

The functions aren't on api.d.o yet, but those are the URLs that will find them.

I think this is clear enough, it doesn't need explicit code examples.

Automatically closed -- issue fixed for 2 weeks with no activity.