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 <anssi.kaariai...@thl.fi> 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 <anssi.ka...@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).
>
> 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 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.
--
-- 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.
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.
