#29907 closed New feature (wontfix)
Allow QuerySet.get() and filter() to accept a positional argument for implicit primary key filtering
Reported by: | Antoine | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Pull Requests: | How to create a pull request | ||
Description ¶
I'm creating this ticket to see if there is interest to implement positional arguments in queryset filtering.
Current situation ¶
Currently the only way to use positional arguments to filter can be either:
- Passing a single or multiple Q objects:
MyClass.objects.filter(Q(key=value)) MyClass.objects.filter(Q(key=value), Q(other_key=value))
- Passing a couple is also working (not sure if this is a happy accident)
MyClass.objects.filter((key, value))
- Combination of both is also proven to work
MyClass.objects.filter((key, value), Q(other_key=value))
Suggestion ¶
My feature suggestion is to leverage the case when a non-Q / non couple object is passed, so it implicitly interpreted as the value for the model's pk
.
This could ease/simplify code by omitting pk
when this is the only filter used:
MyClass.objects.get(value) # Translates into: MyClass.objects.get(pk=value)
or
MyClass.objects.filter(value) # Translates into: MyClass.objects.filter(pk=value)
or
MyClass.objects.filter(Q(value)) # Translates into: MyClass.objects.filter(Q(pk=value))
Do you think it's worth it? It could be leveraged to simplify many situations.
Change History (3)
comment:1 by , 6 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Summary: | Queryset.get(), Queryset.filter(), and Q() with positional arguments → Allow QuerySet.get() and filter() to accept a positional argument for implicit primary key filtering |
comment:2 by , 6 years ago
Hey there, I've personally wished get(pk)
was supported in the past but as Tim said this should be brought to the mailing list to try to get a consensus.
From The Zen of Python, "Explicit is better than implicit." Proposals for design decisions like this are better made on the DevelopersMailingList but I doubt there would be consensus to do this.