On Sep 27, 2013, at 2:56 PM, Anssi Kääriäinen <[email protected]> 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 [email protected] -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
