Settings -> Backup -> Restore on a Postgres-backed Bambuddy aborted
with `cannot drop table printers because other objects depend on it`
when the live DB held orphan tables from removed features. Legacy
`spoolman_slot_assignments` / `spoolman_k_profile` from an earlier
Spoolman integration still sat in the schema with `*_printer_id_fkey`
constraints back to `printers`, so `metadata.drop_all` (which only
knows about ORM tables, no CASCADE) couldn't drop `printers` and the
whole restore aborted before any rows landed.
Replace `metadata.drop_all` with a `pg_tables`-iterating PL/pgSQL DO
block that DROPs every public-schema table with CASCADE, then call
`metadata.create_all` to rebuild the schema. CASCADE removes external
constraints alongside the table, and a "restore" is intentionally
destructive — the user has explicitly chosen to wipe the DB and
replace from backup.
Two regression tests in test_postgres_restore_drop_cascade.py mock
the Postgres engine, capture the SQL stream, and assert (a) the
CASCADE+pg_tables iteration is emitted and metadata.drop_all is
never called, (b) the drop is scoped to public schema so shared
Postgres setups aren't taken out.
SQLite restores go through a separate path and are unaffected.
maziggy
8d82658cd0