When writing hook_update_N() functions to create a new table, it seems natural and obvious to use the module's hook_schema() function to access the current definition of the table to avoid duplicating the table definition in the hook_update_N() function. However, you cannot safely use hook_schema() from within a hook_update_N() function.
Consider the following scenario: You created the module example. Initially, it has no tables, and its initial schema is empty. For version 6.x-1.5, you define a new table T. This means that you create the file M.install and, in it, create the function example_schema() which defines the table T:
function example_schema() {
$schema['T'] = array(
'fields' => array(
'a' => array('type' => 'int'),
'b' => array('type' => 'int'),
)
);
return $schema;
}
You also write an update function to bring module M from version 6.x-1.0 to version 6.x-1.5 by creating table T:
function example_update_6100() {
$schema = drupal_get_schema('M');
$ret = array();
db_create_table($ret, 'T', $schema['T']); // DON'T DO THIS!
return $ret;
}
For the 6.x-1.8 release, M no longer needs the field T.b. So, you update example_schema() to reflect the current schema and add an update function:
<?php
function example_schema() {
$schema['T'] = array(
'fields' => array(
New to DrupalCon? We’ve Got You!
Join our meet-ups before the Welcome Reception, Keynotes, and Lunches to connect with fellow attendees and get the most out of your experience. DrupalCon is as amazing as the community that attends—and that includes YOU! We can’t wait to see you at DrupalCon Atlanta 2025 (24-27 March)!
