Opened 17 years ago
Closed 13 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 , 17 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 , 17 years ago
| Summary: | Docuemtn that functions in QuerySets' parameters are eagerly evaluated. → Document that functions in QuerySets' parameters are eagerly evaluated. |
|---|
comment:3 by , 17 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Not quite sure why I closed this, since I didn't update the documentation.
comment:4 by , 16 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 , 15 years ago
| Severity: | → Normal |
|---|---|
| Type: | → Cleanup/optimization |
comment:8 by , 13 years ago
| Status: | reopened → new |
|---|
comment:9 by , 13 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.