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();'
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?