drush updatedb для одного модуля

Можно ли выполнить функцию обновления одного модуля с помощью Drush? Я вижу, drush updatedbчто не принимает modulename в качестве аргумента и запускает все доступные обновления. Затем есть drush pm-updateтакже проверка новых файлов. в документации сказано:

(так же, как pm-updatecode + updatedb)

Означает ли это, что при запуске drush pm-updateкаждого доступного (более нового выхода update_function) будет выполнено обновление? Есть ли способ только (дБ) обновить только один модуль?

Нет, ты не можешь.

Если вы хотите обновить каждый модуль самостоятельно, обновите только файлы одного модуля и затем запустите updatedb.

На Drush 5.7 вы можете запустить команду drush pm-update --no-core module-name. Drush автоматически создаст резервную копию текущего модуля, загрузит новую версию и предложит обновить базу данных.

Если вы хотите запустить только одно обновление, вы можете запустить drush eval foo_update_33(), например. На практике это немного сложнее, так как вам нужно загрузить файл .install, но не намного.

Вы также можете попробовать решение @macaleaa:

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

ни кажется drush up someproject, ни drush upc someprojectобновить только someprojectмодуль. Другой путь к тому, что вы хотите, через:

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

Здесь обсуждается похожая тема на Drupal.org. Береги себя !

Я использую Drush 5.9 и могу успешно обновить один модуль с помощью этой команды:

drush dl *project*

Так, например, чтобы обновить модуль 'devel':

drush up devel

Я считаю, что теперь это возможно с Drush, используя up:

drush up module_name

У меня была ситуация, в которой таблица создавалась функцией update ( MYMODULE_update_7101), но эта таблица использовалась в коде где-то в каждом очищенном кеше и почти при каждом вызове drush (это было в основном получение имен типов сущностей для всех меню и любых других еще). Бег drush updatedbбежал MYMODULE_update_7101третьим вместо первого.

Я попробовал решение, предложенное @macaleaa и @moshe weitzman:

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

перед запуском drush updatedb, но это не помогло - пробежка не удалась, потому что updatedbснова попытался запустить MYMODULE_update_7101()и выдал ошибку, говоря, что таблица уже существует. По сути, приведенный выше код запустил обновление, но не оставил след в системе, в которой было выполнено обновление. Предположительно, существует множество других вещей, update.phpкоторые необходимо выполнить после запуска каждого обновления, чтобы сохранить номер последней версии модуля в БД и т. Д.

Я update.phpпосмотрел, как на самом деле выполняется каждая функция обновления и что она делает после этого, искал функцию для вызова, которая бы вызывала функцию обновления, а также делал все остальное. Я закончил тем, что добирался до этого:

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

Который я на самом деле побежал с drush:

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

Он запустил обновление, без проблем, но тогда MYMODULE версии 7101 все еще показывался в списке обновлений, когда я запустился updatedb, хотя он работал без ошибок, и все выглядело хорошо при проверке сайта.

Немного взволнован и опоздал на 6 лет, но все хорошо, что хорошо кончается?