Eu tive uma situação em que uma tabela criada por uma função de atualização ( MYMODULE_update_7101
), mas essa tabela estava sendo acessada em código em algum lugar em cada cache limpo e quase todas as chamadas drush (estava basicamente recebendo os nomes dos tipos de entidade para todos os menus e qualquer outra coisa) outro). Correr drush updatedb
estava em MYMODULE_update_7101
terceiro lugar em vez de primeiro.
Tentei a solução sugerida por @macaleaa e @moshe weitzman de execução:
drush php-eval 'module_load_install('MYMODULE');MYMODULE_update_7101();'
antes da execução drush updatedb
, mas isso não ajudou - a execução do drush falhou porque updatedb
tentou executar novamente MYMODULE_update_7101()
e errou, dizendo que a tabela já existia. Basicamente, o código acima executou a atualização, mas não deixou sua marca no sistema em que a atualização foi executada. Presumivelmente, há várias outras coisas update.php
a serem feitas após a execução de cada atualização para armazenar o número da versão mais recente do módulo no banco de dados, etc.
Analisei update.php
como ele realmente executa cada função de atualização e o que faz depois, procurando uma função para chamar que chamaria a função de atualização e também fazer todas as outras coisas. Acabei chegando a isso:
include_once DRUPAL_ROOT . "/includes/update.inc";
$c["results"]["#abort"] = array();
update_do_one("MYMODULE", 7101, array(), $c);
Que eu realmente corri com drush:
drush eval 'include_once DRUPAL_ROOT . "/includes/update.inc"; $c["results"]["#abort"] = array(); update_do_one("MYMODULE", 7101, array(), $c);'
Ele executou a atualização, não há problema, mas a versão 7101 do MYMODULE ainda aparecia na lista de atualizações quando eu corria updatedb
, apesar de executada sem erros e tudo parecia bom na inspeção do site.
Um pouco hacky e 6 anos atrasado, mas tudo está bem quando acaba bem?