mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-08-11 00:30:12 -04:00
fd3f5331f3
Some checks failed
Security Audit / Python Security Analysis (Bandit) (push) Failing after 2s
Security Audit / Container Security Scan (Trivy) (push) Failing after 2s
Security Audit / Backend Security Audit (push) Failing after 2s
Security Audit / Frontend Security Audit (push) Failing after 2s
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. |
||
|---|---|---|
| .. | ||
| routes | ||
| __init__.py | ||