On Sep 27, 2013, at 2:56 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
> 1. What to do if given DB doesn't support cascades in DB (sqlite at least, > no idea of MySQL)? Initial feeling is that Django should do the cascades in > Python code in these cases. It would behave like the standard version, then, yes. > 2. What to do if you have delete signals + db cascades set for given model? > Options are to do nothing at all, give a warning (manage.py check might be > able to do so) or raise an error in model validation. If we document that the _DB variation doesn't fire signals, I believe that's sufficient. > 3. A model definition like A -- db cascade -> B -- cascade in python -> C > is another problematic case. a_obj.delete() will cascade to B, but then that > deletion will fail because of C constraint not cascading. Again possibilities > are do nothing/warn/error Interesting question. I believe we can just document that it won't work properly, because in those DBs that support proper cascading behavior, what you get in the B -> C cascade will be an error. > 4. A slight variation of above - generic foreign key cascades - here it > will be impossible to handle the cascades in DB (unless we want to write > custom triggers for this). And, the inconsistent state left behind will not > be spotted by the DB either as there aren't any constraints in the DB for > generic foreign keys. So, this is slightly worse than #3. We can, of course, just disallow using the _DB variations for generic foreign keys. > 5. Parent cascades: If you have model Child(Parent), then there will be > foreign key from child to parent, but not from parent to child. This means > that DB can't cascade child model deletion to the parent model. So, there is > again possibility for inconsistent state. So, if you have Child -- db cascade > -> SomeModel, and you delete somemodel instance then what to do to get the > Child's parent table data deleted? Either: (a) You disallow that. (b) You allow it, but warn that if you delete the child, the parent is not cleaned up. I lean towards (a). -- The _DB variations should be considered something like .update and .raw; they're for performance benefits where you know you are doing. They don't need to solve every edge case. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
