У меня была ситуация, в которой таблица создавалась функцией 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 лет, но все хорошо, что хорошо кончается?