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

Чи можливо виконати функцію оновлення одного модуля за допомогою друку? Я бачу, drush updatedbякий не приймає ім'я модуля як аргумент і запускає всі доступні оновлення. Потім відбувається drush pm-updateперевірка нових файлів. документація говорить:

(те саме, що pm-updatecode + updatedb)

Чи означає це, що якщо я запускатиму drush pm-updateвсе доступне (новіше оновлення_функції), оновлення буде виконано? Чи є спосіб лише (db) оновити рівно один модуль?

Ні, ти не можеш.

Якщо ви хочете оновити кожен модуль самостійно, оновіть лише файли одного модуля, а потім запустіть оновленийb.

На 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

У мене виникла ситуація, коли таблиця, створена функцією оновлення ( MYMODULE_update_7101), але до цієї таблиці входила в код десь у кожному кеш-пам’яті і майже при кожному виклику друку (це в основному отримання назв типів сутності для всіх меню і будь-якого іншого інше). Біг 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після запуску кожного оновлення існує ціла купа інших речей, щоб зберегти номер останньої версії модуля в db тощо.

Я update.phpпереглянув, як вона насправді виконує кожну функцію оновлення і що вона робить після, шукаючи функцію для виклику, яка викликала б функцію оновлення, а також виконувати всі інші речі. Я в кінцевому підсумку дійшов до цього:

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

Який я насправді біг із барабаном:

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

Він запустив оновлення, ніяких проблем, але потім MYMODULE версії 7101 все ще з'явився у списку оновлень, коли я запустив updatedb, ТАКОЖ він запускався, не помиляючись, і все виглядало добре при огляді сайту.

Трохи хакіт і 6 років пізно, але все добре, що закінчується добре?