#19580: Unify reverse foreign key and m2m unsaved model querying
-------------------------------------+-------------------------------------
     Reporter:  Anssi Kääriäinen     |                    Owner:  raydeal
         Type:                       |                   Status:  closed
  Cleanup/optimization               |
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  fixed
     Keywords:                       |             Triage Stage:  Ready for
                                     |  checkin
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  1                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Matt Westcott):

 * cc: Matt Westcott (added)


Comment:

 Ran across this while bringing Wagtail up to date with Django main. I
 appreciate that accessing a reverse-FK relation on an unsaved instance is
 undefined behaviour, so this isn't technically a breaking change -
 however, I suspect there could be a lot of code in the wild that's doing
 this unwittingly, in which case this change might be more disruptive than
 expected.

 For example, I had to make this fix:
 
https://github.com/wagtail/wagtail/pull/8028/commits/9e19bf63dbb698a4f57b131b6f8ae92bab7c2606
 - where I'd implemented something approximating an InlineFormSet, but
 neglected to make a special case for the 'create' view, and so it ends up
 querying an unsaved instance to arrive at the initial empty formset. I
 imagine this will be a fairly common gotcha in user code.

 (for the record, Wagtail also does much more esoteric things with faking
 relations on in-memory objects to support previews and saving drafts, but
 I'm willing to take the hit for that :-) )

 Should we consider making this a deprecation warning for now, and adding
 the strict validation in Django 5.x instead? (Admittedly, this isn't the
 sort of thing you can write a startup check for, so it may be that a
 deprecation warning would only help for apps that have good test coverage
 anyhow.)

-- 
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:56>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d6563b503f09a89bbc04b9ee7266d835%40djangoproject.com.

Reply via email to