When you are writting complicated drupal module update functions it’s often necessary to run and re-run the update function over and over for testing purposes until you reach perfection.
But when you run “drush updb” after the required update function has already been run, your drush updb will simply say there is nothing to update. But, but, I want to run the update again you say! And since you are a well accomplished drupal developer you could go into the mysql system table and modify the version of the module manually and then you’ll be running your test update function again just fine.
BUT why do that when a simple drush module can do it for you.
Rollback the system table so that drupal thinks it has not run the update for myJeff_module version 12
drush uroll --module=myJeff_module --version=12
–module module to change the update function version on
–version Version to set to roll back to
I’m leaving the debugging output in there for now. It just prints the data structure of the version that the update function is currently at, and then the data structure of the system table element after the uroll has run. This just gives you a warm fuzzy feeling that it actually did something.
The output should look something like this:
drush uroll --module=vcd_admin --version=2 Array ( [name] => vcd_admin [schema_version] => 3 ) Array ( [name] => vcd_admin [schema_version] => 2 )
Just put the uroll.drush.inc file in your ~/.drush directory.
By writing more and more update functions you’ll learn the guts of drupal quickly and eventually not have to repeat a bunch of error pron mouse clicks on a production server.