Opened 16 years ago
Closed 12 years ago
#10466 closed Cleanup/optimization (duplicate)
Document that functions in QuerySets' parameters are eagerly evaluated.
Reported by: | liangent | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | liangent@… | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
if i write code like this:
qs = MyModel.objects.filter(dt__lte=datetime.datetime.now)
and execute it at time A, then save qs
somewhere.
later, at time B, i call for obj in qs
to get the object list. as the documentation says, database query is executed at time B. however, it seems that the value of dt__lte
was fetched at time A (ie. datetime.datetime.now
was evaluated at time A), and i think datetime.datetime.now
should be evaluated at time B (if i wrote
qs = MyModel.objects.filter(dt__lte=datetime.datetime.now())
, it should be evaluated at time A). it seems to go against "QuerySets are lazy", doesn't it?
Change History (9)
comment:1 by , 16 years ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Summary: | functions as QuerySets' parameters are not lazy → Docuemtn that functions in QuerySets' parameters are eagerly evaluated. |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 16 years ago
Summary: | Docuemtn that functions in QuerySets' parameters are eagerly evaluated. → Document that functions in QuerySets' parameters are eagerly evaluated. |
---|
comment:3 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Not quite sure why I closed this, since I didn't update the documentation.
comment:4 by , 15 years ago
This has bitten me before as well. You might also want to add that if you pass that QuerySet as a parameter to a view in your url config, the QuerySet will have the datetime of server start, since it is only evaluated once.
And also add a way to work around this limitation? (for both the original problem and my url conf problem)
comment:5 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Cleanup/optimization |
comment:8 by , 12 years ago
Status: | reopened → new |
---|
comment:9 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
I'm closing this as a duplicate of #20241.
Even though this ticket is much older, the other one has some explanations as to why fixing this bug is tricky.
Personally, I think this feature should be removed since it doesn't the only thing it does (from what I understand) is basically save the user from typing a pair of parentheses.
I'm going to call this one invalid, but it does need better documentation.
The queryset's evaluation against the database is lazy. The parameter evaluation (unless it's a database query) is done when you create the queryset. It's fairly complicated to arrange for this to be otherwise in all cases and rather than mess around with when it does and doesn't work, we always have eager parameter evaluation.
I will add some documentation, but the behaviour isn't going to change. Sorry about that. :-)
Changing the title to reflect how we'll resolve this.