After far too long, this ticket has been created:
https://code.djangoproject.com/ticket/21961
If there's general consensus that this feature is worth working on, I'll see
about a 1.7-targeted patch for it.
On Sep 28, 2013, at 10:16 AM, Anssi Kääriäinen <[email protected]> wrote:
>
>
> On Saturday, September 28, 2013 4:31:18 AM UTC+3, Xof wrote:
>
> 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).
>
> Yes, I think we need to disallow #4 and #5. It will be too easy to miss
> these edge cases, as things will seem to work correctly.
>
> The data model in #4 is this:
>
> class SomeModel(models.Model):
> fk = models.ForeignKey(SomeOtherModel, on_delete=DB_CASCADE)
> gen_rel = GenericRelation(GFKModel)
>
> This is quite an edge case, but it would be nice to detect & prevent this. I
> am not sure if GenericRelation actually respects to_delete currently at all.
>
> For multitable inheritance it will be easiest to prevent db-cascades in all
> foreign keys, both from parent models and child models. That is likely overly
> restrictive, the only really problematic case seems to be db cascade foreign
> key in child models. But it will be possible to improve multitable cascades
> later on, so lets just get something working implemented first.
>
> Probably time to move this into Trac... You can open a ticket there and
> assign it to yourself.
>
> - Anssi
>
> --
> 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.
--
-- 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/B85349C0-056B-451B-9A7F-039F6FF886AC%40thebuild.com.
For more options, visit https://groups.google.com/groups/opt_out.
