Help detect execute-then-slice mistakes
Bug #608679 reported by
Jeroen T. Vermeulen
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Storm |
New
|
Undecided
|
Unassigned | ||
Bug Description
Sometimes we hit performance bugs because we accidentally execute queries before slicing them. We can end up retrieving large result sets and slicing them client-side when we meant to limit-offset-slice the query itself. The application framework can hide this pattern from us.
It would be useful if we could mark a ResultSet so that it can't be issued as-is without a slice, count(), remove() or somesuch. (If it does get sliced, counted, or removed then it may still be costly on the server but we won't retrieve large unwanted result sets). In Launchpad we would do this when passing a query to the batch navigator.
Revision history for this message
| Robert Collins (lifeless) wrote | #1 |
To post a comment you must log in.
See also our decorator which is used in the batch navigator ( I think) to error if we get a large slice back; this is a nice proactive form of it that should trigger in dev environments.
OTOH sometimes we /know/ that a particular table is fixed in length, so it would be nice to be able to opt back *out* of this when we know that.