[Django] #29907: Queryset.get(), Queryset.filter(), and Q() with positional arguments
Django
-------------------------------------+-------------------------------------
Reporter: antwan | Owner: nobody
Type: New | Status: new
feature |
Component: Database | Version: master
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29907>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
implicit primary key filtering
-------------------------------------+-------------------------------------
Reporter: antwan | Owner: nobody
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
From [https://www.python.org/dev/peps/pep-0020/ 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29907#comment:1>
Django
implicit primary key filtering
Reporter: antwan | Owner: nobody
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29907#comment:2>
Django
implicit primary key filtering
Reporter: antwan | Owner: nobody
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
[https://groups.google.com/d/topic/django-
developers/T7ZLFeM0Ia8/discussion django-developers thread]
--
Ticket URL: <https://code.djangoproject.com/ticket/29907#comment:3>