Add support for database-level cascading options
|Reported by:||Xof||Owned by:||nobody|
|Component:||Database layer (models, ORM)||Version:||master|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Per a discussion on -developers, this ticket is to document this proposed new feature.
The general idea is to allow developers to specify that the database itself, rather than Django, should implement foreign key constraints where possible. The database can be considerably more efficient, and often can avoid locking situations, in a way that the Django backend can't.
The proposal is to add a models.CASCADE_DB, models.SET_NULL_DB, models.PROTECT_DB constants. These specify that the appropriate functionality is to be implemented in the database if the database supports it; otherwise, they are implemented in the Django core as now.
Some potential design issues with proposed solutions:
- It is not an error to specify the _DB version with a database that doesn't support it. Instead, you get the non-_DB version.
- The _DB version does not fire signals; this will need to be documented.
- If a model A references a model B using CASCADE_DB, but model B references model C using regular CASCADE, a deletion of A won't cascade all the way to C. This needs to be documented. Another possibility is to make this an error condition and have model validation fail, but that seems excessive.
- The _DB version is disallowed on generic foreign keys, because that way madness lies.
- The implicit foreign key created from child to parent in model inheritance is never the _DB version. This is a shame, but there are two issues:
a) Since it's created implicitly, there's no place to put it.
b) Even if we extended the mechanism to allow manual specification of the key, deleting the parent wouldn't automatically delete the child.
Change History (11)
comment:1 Changed 22 months ago by mjtamlyn
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Triage Stage changed from Unreviewed to Accepted
comment:10 Changed 4 months ago by timgraham
- Summary changed from ForeignKey.on_delete supports database-level cascading options to Add support for database-level cascading options