#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 , 13 years ago
| Resolution: | → needsinfo |
|---|---|
| Status: | new → closed |
| Type: | Uncategorized → Bug |
comment:2 by , 12 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 , 12 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 , 9 years ago
| Has patch: | set |
|---|---|
| Needs documentation: | unset |
| Patch needs improvement: | set |
PR with comments for improvement.
comment:9 by , 9 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
comment:10 by , 9 years ago
| Patch needs improvement: | unset |
|---|
comment:11 by , 9 years ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:12 by , 9 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 , 9 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.