Ретроспективное исправление для подключения обновления n() в текущем выпуске

Мне нужно внести исправление в функцию hook_update_N() в файле .install, которая вызывает ошибки ограничений SQL при обновлении некоторых пользователей до новой версии выпуска. Оригинал работал нормально при условии, что они работали update.php вручную сразу после обновления. Но некоторые пользователи начали использовать сайт до запуска update.php а затем, когда они запустили его, они получили ошибки SQL. Также некоторые сценарии автоматического обновления получают ошибку. В обоих случаях требуемое обновление не выполненный.

Подробности о предыстории находятся в выпуске https://www.drupal.org/node/2706119

Исправление сделано и готово, но я не обязательно хочу выпускать еще один релиз, как это было всего три месяца назад для последнего релиза. 18 тысяч пользователей обновились, но 34 тысячи еще не обновились, поэтому было бы хорошо, если бы исправленная функция update_n() могла каким-то образом быть добавлена в текущую версию. Возможно ли это? Может ли git пометить новую фиксацию в текущей версии, а затем я ее переиздам опять?

 1
updating
Author: Jonathan1055, 2016-07-11
Source

2 answers

Выступая в качестве администратора проекта на drupal.org , насколько я помню, вы не можете создать один и тот же релиз дважды; вам нужно создать другой релиз. Вы можете удалить последнюю версию и создать ее заново, но я не уверен, что модуль диспетчера обновлений уведомит пользователей о новой версии; если бы это было так, я думаю, пользователи были бы смущены тем, что их уведомили о новой версии, которая совпадает с их версией.

Если я правильно понимаю, проблема в том, что ваш крючок обновления содержал следующее код.

   $rows_updated = db_update('role_permission')
     ->fields(array('permission' => 'schedule publishing of nodes'))
     ->condition('permission', 'schedule (un)publishing of nodes', '=') ->execute();

  return format_plural($rows_updated, '1 row updated in role_permission table.', '@count rows updated in role_permission table.');

Затем вы изменили его на следующий.

 // Updates done in two stages to avoid integrity constraint violation.
 // @see http://www.drupal.org/node/2706119

 // Select all role ids which already have the new permission value.
 $query = db_select('role_permission', 'rp')
   ->fields('rp', array('rid', 'permission'))
   ->condition('permission', 'schedule publishing of nodes');

 // Delete the rows for these roles which also have the old permission value,
 // as these are no longer needed and should not be updated to the new value.
 $rows_deleted = 0;
 if ($rows_to_delete = $query->execute()->fetchCol()) {
   $rows_deleted = db_delete('role_permission')
     ->condition('rid', $rows_to_delete, 'IN')
     ->condition('permission', 'schedule (un)publishing of nodes', '=')
     ->execute();
 }

 // Now update any other rows which still have the old permission value.
 $rows_updated = db_update('role_permission')
   ->fields(array('permission' => 'schedule publishing of nodes'))
   ->condition('permission', 'schedule (un)publishing of nodes', '=')
   ->execute();

 return format_plural($rows_deleted, '1 row deleted', '@count rows deleted')
   . ', ' . format_plural($rows_updated, '1 row updated', '@count rows updated')
   . ' ' . t('in role_permission table');

Как я понимаю, новый код должен заменить старый код, и ваша проблема в том, что есть пользователи, которые уже запустили обновление обновление #7102. Если это так, то я бы переименовал scheduler_update_7102() (с новым кодом) scheduler_update_7103(). Таким образом:

  • Пользователи, которые не выполнили обновление, не будут запускать старое scheduler_update_7102(), и они не получат ошибку
  • Пользователи, которые уже запустили scheduler_update_7102(), найдут scheduler_update_7103(), который завершает обновление для них.
 0
Author: kiamlaluno, 2016-07-12 08:34:42

Вы можете сбросить статус запроса hook_update_n из приведенного ниже запроса update system set schema_version=0 where name='modulename(hook)';

Затем вы можете запустить update.php таким образом, этот hook_update_n() снова будет работать с вашими последними изменениями.

Также вы можете увидеть эту ссылку для значений schema_version system_schema() почему мы должны установить schema_version '0' вместо '-1'.

Вы можете использовать следующий модуль drush для отката версии обновления в системной таблице. Называется "уролл" для обновления отмена.

Https://github.com/danshumaker/drush-uroll

Использование: drush urall--модуль=mycustommodule--версия=5

Это в сочетании со сценарием перезагрузки резервной копии базы данных позволяет промывать и повторять при написании функций обновления

 2
Author: Yogesh Pawar, 2016-07-11 10:18:36