paul bennett

Drupal: what to do when tables won’t install during module development

Posted on: November 10, 2009

Drupal’s module installation system makes it very easy to extend and customise Drupal sites and to disable and re-enable modules quickly and non-destructively. However, the default way Drupal’s treats modules can get in the way during development.

When building your own modules, it’s common for database table structure to change as project needs become clearer, or even for modules to be built in a “front to back” fashion – where the admin screens and the UI interaction skeleton is built before the underlying processing and data storage code is developed (or finalised).

If this is the case, you may find yourself building an install file late in module development and then wondering why Drupal seems to dutifully ignore it.

Despite being counter-intuitive, this behaviour has some clear benefits. Previously installed modules may have attached database tables, and these tables may still hold valid application data. Drupal’s behaviour ensures that these tables aren’t destroyed when the module is disabled. The module can then be re-enabled later without any data destruction.

To get a module to run an install file, or to re-install successfully, you need to do more than just disable and re-enable the module on the module list screen (/admin/build/modules). This is beacuseĀ  Drupal keeps a record of previously installed modules and won’t reinstall them if they are merely disabled and re-enabled.

The trick to getting your new / updated install file to run is to remove the modules entry from the system database tables. If your module has already created one or more tables, and you want the table structure to be altered or rebuilt, you may also need to remove these tables before re-enabling the module.

Once you’ve disabled your module, removed the related entry from the system table and removed any module-related tables, you can re-enable the module and your install file will be run correctly.

About these ads

8 Responses to "Drupal: what to do when tables won’t install during module development"

It would be helpful if you describe how to remove a module table from a database…

Hi ahimsa,

A handy bit of sql will do the trick:

“drop table TABLENAME;”
;)
Paul

This can also be done though your module (rather than direct interaction with the database) by adding hook_enable and hook_disable implementations as follows:

Just make sure to remove these hooks after module development unless you want user submitted to be lost on disable!

The Code (was removed last time)
/**
* Implementation of hook_install().
* Called when you “check” your module
*/
function modulename_enable() {
drupal_install_schema(‘modulename’);
}

/**
* Implementation of hook_disable().
* Called when you “uncheck” your module
*/
function modulename_disable() {
drupal_install_schema(‘modulename’);
}

Thanks for the tip Lacey – good to know there’s a more “Drupal” way to achieve this :)

Thank you, just what I needed to know. Saved me from pulling my hair out!

Hi Paul and Lacey,
Thanks for the tips but i gotta question for you if i re enable the module does the database loses the content that are previously stored.

As this article outlines, disabling and then re-enabling the module has no effect on existing module-related tables, but if you’re running the install functions again (ie: you’ve disabled your module, removed the related entry from the system table and removed any module-related tables) then your existing db data will be lost.

Trying to run the module install again without removing the old tables will make MySQL complain that the table aready exists UNLESS your install functions include SQL command/s to drop the old tables before the install runs.

Hope that helps :)

Paul

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: