Files
bambuddy/backend
maziggy 49dffd32fd Drop the restore's foreign keys in the database, not in the ORM metadata
Restoring a SQLite backup into PostgreSQL died part-way with

      insert or update on table "library_files" violates foreign key
      constraint "library_files_folder_id_fkey"
      DETAIL: Key (folder_id)=(1) is not present in table "library_folders".

    The import recreates the schema and is supposed to create every table
    without foreign keys, so the order rows arrive in cannot matter; the
    constraints are added back once the data has landed. Phase 1 did that by
    discarding each ForeignKeyConstraint from table.constraints before
    create_all -- which only suppresses the inline REFERENCES clause.
    Table.foreign_key_constraints is derived from the columns' ForeignKey
    objects and was never touched, and when create_all meets a dependency
    cycle it cannot sort, it falls back to emitting those tables' keys as
    separate ALTER TABLE ... ADD FOREIGN KEY statements read from exactly
    that property.

    library_files, library_folders and print_archives form such a cycle, so
    twelve constraints survived across the three of them -- measured against
    a real PostgreSQL by running the old phase verbatim. The same cycle also
    costs those tables their place in sorted_tables, so they were imported
    alphabetically, putting library_files ahead of the library_folders rows
    its folder_id references.

    Phase 1 now creates the tables normally and drops every foreign key from
    pg_constraint afterwards, in the same transaction, scoped to contype 'f'
    in the public schema. That is indifferent to how create_all chose to
    emit them, so a future cycle between other tables cannot bring this
    back. Phase 3 is unchanged.

    This also removes a second fault: the keys were stripped from the
    process-wide Base.metadata and only restored after the drop/create
    transaction, so a failure in between left the running app without them
    until restart. The metadata is no longer modified at all.

    Verified end to end against a real PostgreSQL -- a backup whose child
    rows import before their parents restores cleanly, with all 90
    constraints back afterwards. Four regression tests added.
2026-08-15 14:52:55 +02:00
..