...and do it manually in the delete() handlers of each model. We've hit too many data loss bugs in production from unexpected cascades, e.g., 588994. Disabling this, while making for a little more model work, would cause oversights to fail safely and loudly, with a traceback complaining of a violated foreign key constraint. jbalogh reports they already do this on AMO via monkeypatching Queryset and ModelBase (iirc). (I think we can get away with Queryset at the most if we override delete() in sumo.models.ModelBase.
Summary: Disabled Django's cascading delete → Disable Django's cascading delete
Nice as this is, making the project-wide change isn't a 2.3 release blocker.
Priority: P2 → P4
Looks like this is coming soon to a django near you: http://groups.google.com/group/django-developers/browse_thread/thread/739ee24db746a5dc?hl=en
AMO just upgraded to Django trunk. I don't want to add that much entropy to 2.3 and 2.4, but let's make upgrading a top priority for early Q1. There are a bunch of fixes in there we want. Also, I'm concerned that we've made a lot of assumptions about this behavior and now is not a good time to track them all down.
Assignee: nobody → james
Priority: P4 → P1
Target Milestone: 2.3 → Future
we did this.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 836288
You need to log in before you can comment on or make changes to this bug.