config_install_default_config() is not safe to use in hook_update_N()

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

The latest patch in there removes the last call to it in the upgrade path and makes sure that we can't add new ones, as that would trigger hook_entity_info(), which in turn would throw an exception.

So I *think* we're good here but let's wait until that issue is in.

Wow. I didn't know either and I should know these things.

Should we replace some / most / all of http://drupalcode.org/project/drupal.git/blob/9d73599020c282ed79294dcb41... with this function you found?

I believe you read update_7_to_8_install_default_config wrong. It returns FALSE in this case only:

 $file = new FileStorage(drupal_get_path($type, $name) . '/config');
  if (!$file->exists($config_name)) {
    return FALSE;

It will only return FALSE if the core/modules/history/config/history.bananas.yml file does not exist. If it exists, it will blindly install it again and return TRUE.

My only concern is this scenario:
Assume that we're on 8.0-rc1, and we're supporting head2head upgrade path.

We add a new config file, called history.bananas.yml to core/modules/history/config/history.bananas.yml
In history_update_8666() we call $success = update_7_to_8_install_default_config('module', 'history.bananas');

Even if the return value is the same, this still introduces two different code paths, it's a similar problem to installing a module with a schema, then updating the schema later, for that we added hook_schema_0().

We add a new config file, called history.bananas.yml to core/modules/history/config/history.bananas.yml
In history_update_8666() we call $success = update_7_to_8_install_default_config('module', 'history.bananas');
And then based on $success, we do something important.
This is committed, and is subsequently in 8.0-rc2.

If you run 8.0-rc1..8.0-rc2 updates, $success will be TRUE.
If you run 7.x..8.0-rc2 updates, $success will be FALSE.

Because node_update_8012() already ran module_enable(array('history'));, which would have blanket-installed all of history's config, including history.bananas.yml.

What if we enforce specifying the install of individual config files in updates. When a new file is added, a new update handler gets added for that file. That way regardless of when the update is run the configuration gets installed in the same order.

It seems to be that there should be an issue which uses this functionality for system_update_8046 and therefore need the new parameter.

+++ b/core/includes/update.incundefined
@@ -1462,16 +1462,21 @@ function update_variables_to_config($config_name, array $variable_map) {
+ * @param string $name
+ *   (optional) The owner of the config. Defaults to NULL, in which case the
+ *   name will be derived from the $config_name.
  *
  * @return boolean
  *   True on success, false if config file does not exist.
  */
-function update_7_to_8_install_default_config($type, $config_name) {
+function update_install_default_config($type, $config_name, $name = NULL) {
   // Build the new configuration object.
   $config = Drupal::config($config_name);
 
   // Extract the extension namespace/owner from the configuration object name.
-  $name = strtok($config_name, '.');
+  if (!$name) {
+    $name = strtok($config_name, '.');
+  }

This new functionality is not used in this patch... either we should remove it or convert system_update_8046() to use it.

#17: config-1998204-17.patch queued for re-testing.

Back to RTBC.

Committed 50ae478 and pushed to 8.x. Thanks!