Using model:
{{{
class Foo(models.Model):
fk = models.ForeignKey('self', related_name='fk_rev')
m2m = models.ManyToManyField('self')
}}}
and test case:
{{{
print(Foo().fk_rev.all())
print(Foo().m2m.all())
}}}
We get [] from the first filter, but an error
{{{
ValueError: "<Foo: Foo object>" needs to have a value for field "from_foo"
before this many-to-many relationship can be used.
}}}
from the second filter.
So, m2m fields can't be filtered if the object isn't saved, but reverse fk
fields can be filtered.
There is a (slightly stale) patch for #17541 which makes fk fields and m2m
fields work consistently. The changes in behavior are:
{{{
* Nullable many-to-many and foreign key relations will return an empty
queryset when the relation field is null. For many-to-many this was
previously an error (no change for foreign keys).
* Trying to add objects to a foreign key relation when the relation field
is null is now an error (no change for m2m).
* Trying to use a relation of any kind when the object isn't saved is now
an error (no change for m2m).
}}}
I think we can squeeze these changes in as bug-fixes. These are slight
backwards compatibility changes, but to me it seems that almost always the
changes will be visible only in code that isn't working as intended. If
these are seen as something likely breaking working code, then I don't see
any way to make the APIs consistent.
The #17541 patch is available from:
https://github.com/akaariai/django/compare/ticket_17541
--
Ticket URL: <https://code.djangoproject.com/ticket/19580>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 1
* needs_tests: => 0
* version: 1.4 => master
* needs_docs: => 0
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Design decision needed
Comment:
Reviewing my own ticket as "DDN".
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:1>
* stage: Design decision needed => Accepted
Comment:
Yes, it's better to error loudly on operations that can't work because the
database didn't generate an id for the object yet.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:2>
* easy: 0 => 1
Comment:
I think this would allow removing the two lines added in
a4c20ae85b40c49e28d1b2227208e4f00d7820df.
Marking as "Easy pickings" since rebasing Anssi's original patch might not
be too difficult.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:3>
* status: new => assigned
* owner: nobody => ketanbhatt
Comment:
I will create a new branch, and make the changes made in
https://github.com/django/django/compare/master...akaariai:ticket_17541
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:4>
Comment (by timgraham):
Yes, you should
[https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
/working-with-git/#rebasing-branches rebase the branch] and update the
release notes for 1.11.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:5>
* owner: ketanbhatt =>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:6>
Comment (by mscott250):
Hi,
I'm interested in contributing to Django and have been advised to start
with some of the 'easy pickings' tasks. I've seen it's been unassigned and
is still open, is this something I can pick up?
Cheers,
Michael
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:7>
* owner: => akuzminov
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:8>
Comment (by timgraham):
I left comments for improvement on the rebased
[https://github.com/django/django/pull/7098 PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:9>
Comment (by akuzminov):
Thanks Tim, I'll add more tests next week
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:10>
* cc: olivier.tabone@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:11>
Comment (by Olivier Tabone):
added comments in the PR
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:12>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:13>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:14>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:14>
Comment (by eadhina):
Hey guys, is this ticket still need a fix ?
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:15>
Comment (by John McCann):
Hi there, I was also wondering if further work is needed? From Tim's final
comment in the pull request, it seems that most of the changes from Ansi's
patch still haven't been updated in master. Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:16>
* status: assigned => new
* owner: Andrey Kuzminov => (none)
Comment:
I think someone else could pick this up considering we haven't heard from
Andrey in a while.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:17>
Comment (by Lander Kerbey):
Newbie here, but I've begun reading through this problem and would like to
take a crack at it. Andrey's pull request seems most of the way there, and
if the comments remain valid that gives me a starting point. Thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:18>
Comment (by Tim Graham):
That's a correct assessment of the situation.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:19>
* owner: (none) => harikishen
* status: new => assigned
Comment:
I have used the django framework for some of my projects. I would love to
give back. I would like to work on this bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:20>
* owner: Harikishen H => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:21>
* owner: (none) => Rajesh Veeranki
* status: new => assigned
Comment:
Please review the latest PR, that is rebased with the master here:
https://github.com/django/django/pull/8570
The tests look okay to me. Please suggest any more tests if required.
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:20>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:21>
* needs_better_patch: 0 => 1
Comment:
Comments on
[https://github.com/django/django/pull/8570#pullrequestreview-100000437
PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:22>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:23>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:24>
Comment (by Robert Švab):
Hi everyone, I'm interested in contributing to Django, so would like to
finish this easy pick if needed. From comments on PR I can see there is
only few things left, adjustments to tests and docs. Advise me if there is
anything else left.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:25>
* status: assigned => new
* owner: Rajesh Veeranki => (none)
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:26>
* owner: (none) => Ahsan Shafiq
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:27>
* needs_better_patch: 1 => 0
Comment:
https://github.com/django/django/pull/11807
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:28>
* needs_docs: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:29>
Comment (by Manav Agarwal):
Can I claim this? I think I can move this forward
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:30>
* owner: Ahsan Shafiq => Manav Agarwal
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:31>
* owner: Manav Agarwal => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:32>
* owner: (none) => Pavel Druzhinin
* status: new => assigned
Comment:
I'd like to try finish this
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:33>
Comment (by Pavel Druzhinin):
Need some help with the ticket. PR:
https://github.com/django/django/pull/13784.
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:34>
Comment (by Pavel Druzhinin):
Rebased the previous PR https://github.com/django/django/pull/11807.
I would like to get some clarification on this old ticket, took it under
easy-pickings tag.
https://github.com/django/django/pull/11807#pullrequestreview-344544165 -
this is the last comment from where I started to search next steps to
complete the ticket.
It leads to the undone comments:
1. https://github.com/django/django/pull/8570#pullrequestreview-113177526
Should I move all tests from m2m_through_regress to many_to_many or some
particular tests?
2. https://github.com/django/django/pull/8570#pullrequestreview-113506649
I see prepared changelogs in comment
https://github.com/django/django/pull/11807#issuecomment-612404721, but
don't know where to place them in codebase. Could you explain?
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:35>
* needs_docs: 1 => 0
* needs_tests: 1 => 0
Comment:
PR has been updated https://github.com/django/django/pull/13784
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:36>
* needs_better_patch: 0 => 1
Comment:
Thanks for this patch, however it's not ready for review. Please fix tests
and `isort`.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:37>
Comment (by Pavel Druzhinin):
Replying to [comment:37 Mariusz Felisiak]:
> Thanks for this patch, however it's not ready for review. Please fix
tests and `isort`.
Hello, it seems I need help to fix this error. I'm not sure code from
previous contributor is correct and I don't fully understand the subject
of this bug (m2m relations).
What is better to do: remove label `easy pickings` and try another bug or
someone could help me with fixing this bug?
P.S. Please, don't think for nagging. I really don't want to drop the
ticket silently and want to continue to contribute at the same time.
Thanks in advance with your advice how best to proceed.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:38>
* owner: Pavel Druzhinin => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:39>
* owner: (none) => Pavel Druzhinin
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:40>
* owner: (none) => raydeal
Comment:
I would like to look at code and try to improve the patch.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:39>
Comment (by raydeal):
Replying to [comment:38 Pavel Druzhinin]:
> Replying to [comment:37 Mariusz Felisiak]:
> > Thanks for this patch, however it's not ready for review. Please fix
tests and `isort`.
>
> Hello, it seems I need help to fix this error. I'm not sure code from
previous contributor is correct and I don't fully understand the subject
of this bug (m2m relations).
> What is better to do: remove label `easy pickings` and try another bug
or someone could help me with fixing this bug?
>
> P.S. Please, don't think for nagging. I really don't want to drop the
ticket silently and want to continue to contribute at the same time.
Thanks in advance with your advice how best to proceed.
Would you like to carry on with the ticket? After reading comments and
code my understanding is to make FK reverse working the same way as m2m
when id=None, what is done in code, but message is a bit different, it
would be good to have similar message in both cases. It will require amend
m2m tests as well after update with current django version.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:40>
Comment (by Asif Saifuddin Auvi):
Replying to [comment:40 raydeal]:
> Replying to [comment:38 Pavel Druzhinin]:
> > Replying to [comment:37 Mariusz Felisiak]:
> > > Thanks for this patch, however it's not ready for review. Please fix
tests and `isort`.
> >
> > Hello, it seems I need help to fix this error. I'm not sure code from
previous contributor is correct and I don't fully understand the subject
of this bug (m2m relations).
> > What is better to do: remove label `easy pickings` and try another bug
or someone could help me with fixing this bug?
> >
> > P.S. Please, don't think for nagging. I really don't want to drop the
ticket silently and want to continue to contribute at the same time.
Thanks in advance with your advice how best to proceed.
>
> Would you like to carry on with the ticket? I can help you. After
reading comments and code my understanding is to make FK reverse working
the same way as m2m when id=None, what is done in code, but message is a
bit different, it would be good to have similar message in both cases. It
will require amend m2m tests as well after update with current django
version.
you should take over the ticket and create a new PR as it seems he is not
able to fix the issue
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:41>
Comment (by Pavel Druzhinin):
Replying to [comment:41 Asif Saifuddin Auvi]:
> Replying to [comment:40 raydeal]:
> > Replying to [comment:38 Pavel Druzhinin]:
> > > Replying to [comment:37 Mariusz Felisiak]:
> > > > Thanks for this patch, however it's not ready for review. Please
fix tests and `isort`.
> > >
> > > Hello, it seems I need help to fix this error. I'm not sure code
from previous contributor is correct and I don't fully understand the
subject of this bug (m2m relations).
> > > What is better to do: remove label `easy pickings` and try another
bug or someone could help me with fixing this bug?
> > >
> > > P.S. Please, don't think for nagging. I really don't want to drop
the ticket silently and want to continue to contribute at the same time.
Thanks in advance with your advice how best to proceed.
> >
> > Would you like to carry on with the ticket? I can help you. After
reading comments and code my understanding is to make FK reverse working
the same way as m2m when id=None, what is done in code, but message is a
bit different, it would be good to have similar message in both cases. It
will require amend m2m tests as well after update with current django
version.
>
>
> you should take over the ticket and create a new PR as it seems he is
not able to fix the issue
I agree with this proposal, you could change an assignee. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:42>
Comment (by Ayush Joshi):
raydeal if you are currently unable to work on this ticket then you can
assign it to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:43>
Comment (by raydeal):
Replying to [comment:43 Ayush Joshi]:
> raydeal if you are currently unable to work on this ticket then you can
assign it to me.
I am working on the ticket
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:44>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:45>
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:46>
Comment (by raydeal):
My patch is implemented using different approach then previous. It changes
behaviour of FK to be the same as M2M.
I went through discussion in this and #17541 ticket and PR for them and
analysed examples.
This information in the ticket
" There is a (slightly stale) patch for #17541 which makes fk fields and
m2m fields work consistently."
may be true 9 years ago, but now it is not consistent with M2M.
I have also tested previous patch
(https://github.com/django/django/pull/13784) locally.
I couldn't find correct rules because M2M worked as always, only changed
behaviour of FK. When object is not saved it raises ValueError, when saved
but related value is Null returns <QuerySet []>, which is not consistent
for me. Why?
Base on doubt from #17541
https://code.djangoproject.com/ticket/17541#comment:8 I asked myself: What
is the difference between not saved object with id (pk) refrerenced from
other object and saved object with field containing Null value referenced
by other object, through FK both, from the relation point of view?
There is no difference - both of them have Null value and making related
query in both cases doesn't make sens.
So finally I came to the conclusion that what M2M is doing is correct - in
both cases it raises error - and it meet some of The Zen of Python rules,
I think :)
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:47>
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:48>
* needs_better_patch: 0 => 1
Comment:
Replying to [comment:47 raydeal]:
> I couldn't find correct rules because M2M worked as always, only changed
behaviour of FK. When object is not saved it raises ValueError, when saved
but related value is None returns <QuerySet []>, which is not consistent
for me. Why?
> Base on doubt from #17541
https://code.djangoproject.com/ticket/17541#comment:8 I asked myself: What
is the difference between not saved object with id (pk) refrerenced from
other object and saved object with field containing None value referenced
by other object, through FK both, from the relation point of view?
> There is no difference - both of them have None value and making related
query in both cases doesn't make sens.
There is a huge difference for me. It's doesn't matter which field is
pointed by m2m field, that's not crucial. The most important thing is that
`Foo()` doesn't exist in the database so any related query makes no sense,
and IMO we should raise an exception only in this particular case. You can
start a discussion on DevelopersMailingList if you don't agree, where
you'll reach a wider audience and see what other think.
Moreover proposed change is not a part of the ticket description, it's
backward incompatible, and was not accepted per se.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:49>
Comment (by raydeal):
Replying to [comment:49 Mariusz Felisiak]:
Right, now I better understand what is expected solution. I am going to
review again previous patch and change this one.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:50>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:51>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:52>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:53>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:54>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"7ba6ebe9149ae38257d70100e8bfbfd0da189862" 7ba6ebe9]:
{{{
#!CommitTicketReference repository=""
revision="7ba6ebe9149ae38257d70100e8bfbfd0da189862"
Fixed #19580 -- Unified behavior of reverse foreign key and many-to-many
relations for unsaved instances.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:55>
* 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>
Comment (by Mariusz Felisiak):
> 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.)
IMO deprecation is unnecessary, we raise an exception so it's not
something can be easily missed. Also, this is undocumented behavior and as
far as I'm aware it should be quite rare. If you think deprecation is
necessary, please first start a discussion on the DevelopersMailingList,
where you'll reach a wider audience and see what other think.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:57>
Comment (by Alex Matos):
I work on a large Django codebase and while upgrading it from version 3.2
to 4.2 a lot of code broke due to this change, where code that was once
returning an empty queryset, now raises a `ValueError`. In my opinion,
this change should be fully reverted. The partial update from #33952 is
not enough. I'm pretty sure I'm not alone in this situation. One of
Django's core strengths has always been its stability and breaking user
code without even a deprecation warning should be avoided at all costs.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:58>
Comment (by Adam Sołtysik):
I agree with the above. Why does something like this (where `self` is an
unsaved `User` instance)
{{{Book.objects.filter(author=self).exists()}}}
display a proper `RemovedInDjango50Warning`, while equivalent
{{{self.books.exists()}}}
suddenly crashes? This is totally unexpected.
--
Ticket URL: <https://code.djangoproject.com/ticket/19580#comment:59>