drush updatedb for a single module

Question

Is it possible to perform a single module's update function via drush? I can see drush updatedb which does not take an modulename as argument and runs all available updates. Then there is drush pm-update wich also checks for new files. the documentation says:

(same as pm-updatecode + updatedb)

Does this mean if I run drush pm-update every available (newer update_function exits) update will be perfomed? Is there a way to only (db)update exactly one module?

Answer 1

No, you can't.

If you want to update each module on their own, only update the files of a single module and then run updatedb.

Answer 2

On Drush 5.7 you can run the command drush pm-update --no-core module-name. Drush will automatically backup the current module, download the new version and prompt you to update the database.

Answer 3

If you want to run just one update, you can run drush eval foo_update_33(), for example. In practice, it is a little more complex than that as you have to load the .install file but not much.

You can also try @macaleaa solution :

drush php-eval 'module_load_install('my_module');my_module_update_7XXX();'

Answer 4

neither drush up someproject, nor drush upc someproject seem seem to update only the someproject module. A different way to that what you want is through :

drush dl someproject #use --select option to be prompted for a module version
                     #this will overwrite your exising module's files
                     #backup your modules files with --backup, yourself, use a VCS to revert
drush updb           #run available database update scripts

Here is discussion a similar topic on Drupal.org. Take care !

Answer 5

I'm using Drush 5.9, & can update a single module successfully with this command:

drush dl *project*

So, for example, to update the 'devel' module:

drush up devel

Answer 6

I believe this is now possible with Drush, using up:

drush up module_name

Answer 7

I had a situation in which a table created by an update function (MYMODULE_update_7101), but that table was being accessed in code somewhere in every cache clear and almost every drush call (it was basically getting the names of entity types for all the menus and whatever else). Running drush updatedb was running MYMODULE_update_7101 third instead of first.

I tried the solution suggested by @macaleaa and @moshe weitzman of running:

drush php-eval 'module_load_install('MYMODULE');MYMODULE_update_7101();'

before running drush updatedb, but this didn't help - the drush run failed because updatedb tried again to run MYMODULE_update_7101() and errored out, saying the table already existed. Basically, the above code had run the update, but not left its mark on the system that the update had been run. Presumably there is a whole bunch of other stuff update.php has to do after running each update to store the latest version number for the module in the db, etc.

I went through update.php to see how it actually runs each update function and what it does after, looking for a function to call that would call the update function and also do all the other stuff. I ended up getting to this:

include_once DRUPAL_ROOT . "/includes/update.inc";
$c["results"]["#abort"] = array();
update_do_one("MYMODULE", 7101, array(), $c);

Which I actually ran with drush:

drush eval 'include_once DRUPAL_ROOT . "/includes/update.inc"; $c["results"]["#abort"] = array(); update_do_one("MYMODULE", 7101, array(), $c);'

It ran the update, no problem, but then MYMODULE version 7101 still showed up in the updates list when I ran updatedb, ALTHOUGH it ran without erroring out and everything looked good on inspection of the site.

A bit hacky and 6 years late, but all's well that ends well?