#19222 closed Cleanup/optimization (fixed)
Clarify that custom managers don't apply to intermediate joins
Reported by: | Andrew Badr | Owned by: | Yanik Koval |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I have a custom Manager to filter out model instances with where the field deleted
is True
. I'm using an ORM query that looks like user1.page_set.filter(membership__user=user2)
.
My expectation is that Membership
objects with the deleted flag set are not included in the query. Instead, they are being included.
Change History (16)
comment:1 by , 12 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
Type: | Uncategorized → Bug |
comment:2 by , 11 years ago
class BagelManager(Manager): use_for_related_fields = True def get_query_set(self): return super(BagelManager, self).get_query_set().filter(deleted=False) class Bagel(Model): deleted = BooleanField() objects = BagelManager() all_bagels = Manager() def __str__(self): return "deleted" if self.deleted else "active" class Customer(Model): bagels = ManyToManyField(Bagel)
>>> Bagel.objects.create(deleted=False) <Bagel: active> >>> Bagel.objects.create(deleted=True) <Bagel: deleted> >>> Bagel.all_bagels.all() [<Bagel: active>, <Bagel: deleted>] >>> Bagel.objects.all() [<Bagel: active>] >>> Bagel.objects.filter(deleted=True) []
Correct so far... deleted bagel is invisible through default manager
>>> c = Customer.objects.create() >>> c.bagels.add(*Bagel.all_bagels.all()) >>> c.bagels.all() [<Bagel: active>] >>> c.bagels.filter(deleted=True) []
Still good... deleted bagel is invisible to related fields
>>> Customer.objects.filter(bagels__deleted=True) [<Customer: Customer object>]
Here's the problem. The query join sees the deleted bagel. I would expect queries through relations to see the same data as the relations themselves.
This should either be fixed or documented as a known limitation.
comment:3 by , 11 years ago
Resolution: | needsinfo |
---|---|
Status: | closed → new |
comment:4 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Type: | Bug → Cleanup/optimization |
I don't think this a behavior that's going to change, so documentation seems like the way to go. If you'd like to write a patch, I'll be happy to review it.
comment:5 by , 9 years ago
Keywords: | use_for_related_fields added |
---|
comment:6 by , 9 years ago
Description: | modified (diff) |
---|---|
Keywords: | use_for_related_fields removed |
Summary: | Documentation for use_for_related_fields should clarify that it doesn't work for intermediate joins → Clarify that custom managers don't apply to intermediate joins |
Version: | 1.4 → master |
comment:7 by , 9 years ago
Easy pickings: | set |
---|---|
Needs documentation: | set |
Owner: | changed from | to
Status: | new → assigned |
comment:8 by , 8 years ago
Has patch: | set |
---|---|
Needs documentation: | unset |
Patch needs improvement: | set |
PR with comments for improvement.
comment:9 by , 8 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:10 by , 8 years ago
Patch needs improvement: | unset |
---|
comment:11 by , 8 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:12 by , 8 years ago
yanikkoval, not sure why you assigned yourself to the ticket. In case you didn't see it, we have a patch awaiting review linked in comment:8.
comment:14 by , 8 years ago
Easy pickings: | unset |
---|
I felt the existing proposal is more verbose than needed, so I created an alternate PR.
Attempted to reproduce this, but require more info on model relationships.