Relatie "discourse_automation_automations" herstellen van 3.3beta1 naar 3.5beta7

Installatie Hosting
1

Trying to restore a database from

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

to current. I copied the same app.yml and am restoring (new VM and trying to sidestep the pg upgrade, though maybe I should try that instead of the restore)

I’m getting this error:

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

Seems like another case of some migration getting checked back in and this site got built during those few commits.

I don’t know what to do, though. Maybe I delete the migration that tries creating this table?

Old database is on 20240122015630 and new is 20250617085536.

I see this in the new source:

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

But somehow this migration doesn’t know not to do that one? That table has the same fields on both. Maybe I just delete that migrations from 2019?

2

Ik denk dat 3.3beta1 was vóór de plugin werd opgenomen in de core in april. Kan dit tot problemen leiden - bijvoorbeeld, doordat de plugin nu deel uitmaakt van de core terwijl deze nog steeds afzonderlijk wordt geïnstalleerd via app.yml?

3

Dat is een goed idee, maar dat is het niet. Ik neem het niet nog een keer op. Ik vraag me af of ik het misschien had moeten proberen toe te voegen (maar ik zie het niet bij een snelle blik). Mijn huidige idee is om alle automatietabellen (ze zijn leeg) op de oude site te verwijderen, een nieuwe back-up te maken en te proberen die te herstellen.

1 like
4

Well, and then it failed because discourse_automations_automations was missing. :person_shrugging:

5

Dus ik heb deze verwijderd:

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

en waarschijnlijk had ik 20190601000001_create_automations_table.rb moeten verwijderen, maar in plaats daarvan heb ik code toegevoegd om te controleren of de tabel bestaat (ik denk dat ik een ander probleem had toen ik hem verwijderde?).

En uiteindelijk heb ik het hersteld.

En als ik opnieuw opbouw, krijg ik dezelfde fouten wanneer de database probeert te migreren.

Dus op de een of andere manier moet ik Rails ervan overtuigen dat deze migraties al, eh, zijn uitgevoerd. Dus toen heb ik dit geprobeerd:

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

En dat werkte ook niet.

Ik denk dat ik misschien alleen die van 2021 moet overslaan? Of misschien 202105?

Maar de versie die draait is van januari 2024.

Ik kon de eerste database (voordat ik met schema_migrations had geknoeid) herstellen op de oude server, dus ik ben in ieder geval terug waar ik begon. Ik denk dat ik moet weten hoe ik de commits en migraties op een bepaalde manier kan bekijken die ik niet ken.

1 like
6

Kunnen we dit onderwerp sluiten? Of verplaatsen naar Dev of Installation > Hosting als je het open wilt laten?

7

Ja. Je kunt het sluiten. Ik weet niet zeker of het ooit iemand anders zal overkomen, dus dit is misschien nuttig of misschien ook niet.