Slicing of Storm result sets overrides previous slices
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Storm |
New
|
Undecided
|
Unassigned |
Bug Description
Code in a database class like:
return self.all_
will subsequently be batched by the API. The batching code causes the result set to get sliced again, which ignores the previous slice. So, if quantity=3 and the batching size=5 then the batch returned will actually have 5 items.
Notes:
all_active is a storm ResultSet (or SQLObjectResultSet works identically).
The effect of slicing is only of setting start and limit attributes on the result set. Another slice will override it ignoring the previous slicing.
So where in python you'd expect
>>> [1, 2, 3, 4, 5][:3][:5]
[1, 2, 3]
In Storm, (giving that find() here returns at least 5 objects), you'd get:
>>> results = store.find(
[1, 2, 3, 4, 5]
description: | updated |
Changed in launchpad-foundations: | |
status: | New → Triaged |
importance: | Undecided → Low |