Восстановление связи «discourse_automation_automations» из 3.3beta1 в 3.5beta7

Поддержка Самостоятельное хостинг
1

Пытаюсь восстановить базу данных из

    <meta name="generator" content="Discourse 3.3.0.beta1-dev - https://github.com/discourse/discourse version a4022f69f31af611bc0e21258b0ccb77dec38ba3">

в текущую. Я скопировал тот же app.yml и выполняю восстановление (новая виртуальная машина, пытаюсь обойти обновление PostgreSQL, хотя, возможно, стоит попробовать именно обновление вместо восстановления).

Получаю следующую ошибку:

PG::DuplicateTable: ERROR:  relation "discourse_automation_automations" already exists

Похоже, это ещё один случай, когда миграция была случайно добавлена обратно, и этот сайт был собран в течение этих нескольких коммитов.

Не знаю, что делать. Может, удалить миграцию, которая пытается создать эту таблицу?

Старая база данных находится на версии 20240122015630, новая — на 20250617085536.

В новом исходном коде вижу следующее:

db/migrate/20190601000001_create_automations_table.rb:    create_table :discourse_automation_automations do |t|

Но почему-то эта миграция не понимает, что не должна выполнять это действие? Поля в таблице одинаковы в обоих случаях. Может, просто удалить эту миграцию от 2019 года?

2

По-моему, версия 3.3beta1 вышла до того, как плагин был включён в ядро в апреле. Может ли это привести к каким-либо проблемам — например, из-за того, что плагин теперь входит в состав ядра, но при этом также установлен отдельно через app.yml?

3

Это хорошая идея, но это не то. Я не буду включать это снова. Интересно, может, мне стоило попробовать добавить это (но при беглом просмотре я этого не вижу). Моя текущая идея — удалить все таблицы автоматизации (они пустые) на старом сайте, сделать новую резервную копию и попробовать восстановить её.

4

Что ж, а затем это не сработало, потому что отсутствовало discourse_automations_automations. :person_shrugging:

5

Итак, я удалил эти файлы:

20210108134117_add_pending_pms_table.rb
20210512090204_add_timestamps_to_automations.rb
20210530122323_move_triggers_to_fields.rb
20211119103353_adds_discourse_automation_user_global_notice.rb
20230412120414_add_prefers_encrypt_field_to_pending_pms.rb

И, вероятно, следовало бы также удалить 20190601000001_create_automations_table.rb, но вместо этого я добавил код проверки unless table exists (кажется, когда я его удалял, у меня возникла другая проблема?).

И, наконец, мне удалось восстановить базу данных.

Однако при пересборке я получаю те же ошибки, когда база данных пытается выполнить миграции.

Похоже, мне нужно каким-то образом убедить Rails, что эти миграции уже были выполнены. Поэтому я попробовал следующее:

INSERT INTO schema_migrations(version) VALUES
('20190601000001'),
('20210108134117'),
('20210512090204'),
('20210530122323'),
('20211119103353'),
('20230412120414');

Но это тоже не помогло.

Возможно, нужно просто пропустить те миграции, которые относятся к 2021 году? Или, может быть, к маю 2021?

Но версия, которая сейчас работает, относится к январю 2024 года.

Мне удалось восстановить первую базу данных (до того, как я начал возиться с таблицей schema_migrations) на старом сервере, так что хотя бы я вернулся в исходное состояние. Похоже, мне нужно научиться по-другому просматривать коммиты и миграции.

6

Можем ли мы закрыть эту тему? Или перенести её в Development или #installation:hosting, если вы хотите оставить её открытой?

7

Да. Вы можете закрыть его. Неясно, произойдёт ли это когда-либо с кем-то ещё, так что это может быть полезно, а может и нет.