Data Integrity & Transactions

This guide explains how reverse bindings are persisted, what the default transaction guarantees look like, and how to treat reverse OneToOneField relationships safely. For reference implementations, check Single binding (Company ↔ Department) and Multiple binding (Company ↔ Projects).

Transactional saves

Note

By default, the mixin wraps the entire update in a single django.db.transaction.atomic() block (reverse_relations_atomic=True). If any virtual field raises an error, the whole operation rolls back. You can opt out with reverse_relations_atomic=False if you prefer to persist changes field-by-field.

Unbind before bind

Note

Within each field’s update, the mixin unbinds rows before binding new ones. This avoids transient uniqueness errors on OneToOneField or ForeignKeys with unique=True, as the old relation is cleared before the new one is claimed.

One-to-one specifics

Note

Treat OneToOneField relations as single-select fields (multiple=False). If the reverse relation is non-nullable, you must configure required=True or make the underlying database field nullable. Otherwise, unbinding an object would raise an IntegrityError.

See also

  • Recipes — End-to-end single and multiple binding examples.

  • Core Concepts — Lifecycle summary and transaction overview.

  • Caveats — Edge cases and operational considerations.