In the #281405: Drupal 7.x can't be installed with memory_limit=32M discussion, catch suggested we attempt to break update functions out of the .install file, into an update.inc file. Ideally this would shave 500k, and 7 seconds off a base Drupal install.

Unfortunately, drupal_install_modules() does require the .update.inc files to be loaded, which means we may need additional work to make this work.

Attached is a base patch to move the hook_update_n() files, and the hook_update_dependencies() functions into a separate update.inc file.

CommentFileSizeAuthor
#3 281405_4.patch206.52 KBmikejoconnor

Comments

Anonymous’s picture

watching

Crell’s picture

No patch attached. :-( But I'm interested in this as well.

mikejoconnor’s picture

Status: Active » Needs review
StatusFileSize
new206.52 KB

Sorry, I forgot the attachment, here is the actual patch.

I've applied this locally, and it doesn't seem to make a significant difference in the install time, however it did slighly lower the memory consumption.

Without the patch

Peak memory usage was 29.76 MB [14.97 sec, 27.46 MB]

With the patch

Peak memory usage was 29.13 MB [14.61 sec, 26.84 MB]

Status: Needs review » Needs work

The last submitted patch, 281405_4.patch, failed testing.

tstoeckler’s picture

There is no drupal_install_modules() in D7.
module_enable() calls drupal_get_schema_versions though, so the problem is the same.
The only reason it is calling that is to set the schema version (drupal_set_installed_schema_version).
I don't really see a feasible way around that or a way to get the Schema version without including and parsing the whole update.inc

Anonymous’s picture

I would suggest a defined constant like HOOK_SCHEMA_VERSION that defines the latest N of hook_update_N where HOOK is replaced by the module name.

I would suggest a file hook_N.schema where N is the latest hook_update_N number, hook is replaced by the module name and that this file is included from within hook_schema and that hook_schema be modified to accept the schema version.

define('FOO_SCHEMA_VERSION', '7000');

function foo_schema ($schema_version = FOO_SCHEMA_VERSION) {
  $schema_file = "foo_${schema_version}.schema";
  include $schema_file;
  return $schema;
}

The hook_N.schema file would not contain a function but only the $schema definition.

  $schema['foo'] = array(
    ...
  );

In the hook_update_N one could then include the schema file by calling the hook_schema implementation and then using it's own version of the schema.

function foo_update_7001(&$sandbox) {
  $schema = foo_schema(7001)
  db_add_field('foo', 'col2', $schema['foo']['col2']);
  return t('Added col2 to table foo.');
}

This in general will keep the install file smaller and also allow for tracking the changes to the schema in separated files. The hook_update_N could then be separated into hook_N.update files allow each update to be included individually. The update system would know where to begin and then end with HOOK_SCHEMA_VERSION. So a file foo_7001.update would be included that defines the foo_update_7001 function and then is executed.

tstoeckler’s picture

That sounds like a terrific idea!
I'm not sure, whether we should split .install and .schema though. Since modules are automatically installed and uninstalled in Drupal 7 hook_schema will be the only hook in .install for a lot of modules.
Shouldn't hold up a patch, though either way.

pasqualle’s picture

Status: Needs work » Closed (duplicate)