drush updatedb dla pojedynczego modułu

Czy można wykonać funkcję aktualizacji pojedynczego modułu poprzez drush? Widzę, drush updatedbktóry nie przyjmuje nazwy modułu jako argumentu i uruchamia wszystkie dostępne aktualizacje. Następnie jest drush pm-updatesprawdzane, czy są nowe pliki. dokumentacja mówi:

(to samo co pm-updatecode + updatedb)

Czy to oznacza, że ​​jeśli uruchomię drush pm-updatekażdą dostępną (nowsze wersje funkcji_wyjścia) aktualizację zostanie wykonana? Czy istnieje sposób na aktualizację tylko (db) dokładnie jednego modułu?

Nie możesz

Jeśli chcesz zaktualizować każdy moduł osobno, zaktualizuj tylko pliki jednego modułu, a następnie uruchom zaktualizowaneb.

W Drush 5.7 możesz uruchomić polecenie drush pm-update --no-core module-name. Drush automatycznie wykona kopię zapasową bieżącego modułu, pobierze nową wersję i poprosi o aktualizację bazy danych.

Jeśli chcesz uruchomić tylko jedną aktualizację, możesz drush eval foo_update_33()na przykład uruchomić . W praktyce jest to trochę bardziej skomplikowane, ponieważ musisz załadować plik .install, ale nie za dużo.

Możesz także wypróbować rozwiązanie @macaleaa:

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

ani drush up someprojectnie drush upc someprojectwydają się aktualizować tylko someprojectmodułu. Innym sposobem na osiągnięcie tego jest:

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

Oto dyskusja na podobny temat na Drupal.org. Dbać !

Korzystam z Drush 5.9 i mogę pomyślnie zaktualizować pojedynczy moduł za pomocą tego polecenia:

drush dl *project*

Na przykład, aby zaktualizować moduł „devel”:

drush up devel

Wierzę, że jest to teraz możliwe dzięki Drush, używając up:

drush up module_name

Miałem sytuację, w której tabela utworzona przez funkcję aktualizacji ( MYMODULE_update_7101), ale do tej tabeli dostęp był gdzieś w kodzie w każdej pamięci podręcznej wyczyszczonej i prawie przy każdym wywołaniu drush (w zasadzie otrzymywał nazwy typów jednostek dla wszystkich menu i cokolwiek innego) jeszcze). Bieganie drush updatedbdziałało MYMODULE_update_7101trzecie zamiast pierwszego.

Wypróbowałem rozwiązanie sugerowane przez @macaleaa i @moshe weitzman dotyczące uruchamiania:

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

przed uruchomieniem drush updatedb, ale to nie pomogło - uruchomienie drush nie powiodło się, ponieważ updatedbpróbowałem ponownie uruchomić MYMODULE_update_7101()i zignorowałem, mówiąc, że tabela już istnieje. Zasadniczo powyższy kod uruchomił aktualizację, ale nie pozostawił znaku w systemie, że aktualizacja została uruchomiona. Przypuszczalnie istnieje wiele innych rzeczy, update.phpktóre trzeba zrobić po uruchomieniu każdej aktualizacji, aby zapisać najnowszy numer wersji modułu w db itp.

Przeszedłem, update.phpaby zobaczyć, jak faktycznie działa każda funkcja aktualizacji i co robi później, szukając funkcji do wywołania, która wywołałaby funkcję aktualizacji, a także wykonała wszystkie inne czynności. Skończyło się na tym, że:

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

Które faktycznie prowadziłem z drush:

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

Uruchomiłem aktualizację, nie ma problemu, ale wtedy wersja 7101 MYMODULE wciąż pojawiała się na liście aktualizacji, kiedy uruchomiłem updatedb, mimo że działała bez błędów i wszystko wyglądało dobrze podczas inspekcji witryny.

Trochę zuchwały i spóźniony o 6 lat, ale czy wszystko dobrze się kończy?