Component‑Translation Table Consistency During Weblate Schema Rollback

No, rolling back a Django migration that modifies the foreign key relationship between the component and translation tables does not automatically preserve data or guarantee referential integrity. Django's migration system manages DDL (Data Definition Language) changes; it does not perform data-level backups. If the migration being rolled back dropped a column or table, that data is permanently removed from the database unless you exported it beforehand.

The Risk of Orphaned Rows

In Weblate, the translation table relies heavily on the component table. When you execute a rollback (python manage.py migrate app [migration_name]), Django executes the reverse of the migration operations. If the operation involves DropField or RemoveConstraint, the data in those fields is deleted.

Furthermore, if the rollback re-adds a foreign key constraint, the operation will fail if the intermediate state allowed for the creation of orphaned rows or null values that violate the new constraint's requirements. PostgreSQL will enforce this upon constraint creation, but Weblate does not provide a native post-rollback cleanup script to rescue or merge these inconsistencies.

Verification Steps

To ensure referential integrity after a schema rollback, you must manually verify the tables:

• Check for Orphaned Translations: Identify translations that no longer point to a valid component.

  SELECT * FROM weblate_translation WHERE component_id NOT IN (SELECT id FROM weblate_component);

• Validate Constraint Compliance: Ensure that no columns marked as NOT NULL contain null values from the rollback process.

  SELECT COUNT(*) FROM weblate_translation WHERE [column_name] IS NULL;

• Schema Alignment: Use Django's internal check to ensure the database state matches your models.

  python manage.py checkmigrations

Manual Data Rescue Requirements

If the rollback resulted in data loss or orphaned records, you must perform the following:

1. Data Restoration: Restore data from a pg_dump snapshot taken prior to the migration.
2. Manual Pruning: Manually delete orphaned rows that cannot be re-linked to component IDs.
3. Constraint Re-application: If the rollback failed due to constraint violations, you must clean the invalid data before the migration can successfully re-apply the constraint.

Does the specific migration in question involve a DROP COLUMN operation or merely an ALTER CONSTRAINT?