- Tables a core migration creates (category_templates, ...) and
MigrationRunner's own log were taken for module tables: only
database.sql was read. coreSchemaTables() reads the up-migrations and
counts the log too.
- A module table that is the parent of a foreign key (telegram_bots)
could not be dropped on its own: the drops run with foreign-key checks
off, and a saved table loses its foreign keys, which name the backup's
other tables.
- No options file (migrate run by hand) and a lines table without pid
no longer warn.
The migration of a restored backup copied watch_folders itself, a table
the Watch module owns: without the module the rows were lost. Core no
longer writes module tables, and keeps no list of them. After the core
tables, every backup table the core does not own (not in database.sql,
not migrated by core, not junk of the old panels) is saved to
Modules/migration/<table>.sql (its definition as legacy_<table>, then
its rows as INSERTs), handed to the installed modules
(LegacyTableMigrationEvent) and dropped; then what is left of
xc_vm_migrate is dropped, so a multi-gigabyte backup does not stay. A
module installed later loads its file into the staging table and copies
it (fromBackup(), discard()). A table that could not be saved keeps the
backup database as it is. The setup page lists the tables saved for
modules.
Divarion_D