Hi Robert,
Testing the current version of StormRangeFactory with a real Launchpad
view, I noticed these issues:
StormRangeFactory.getEndpointMemos(self, batch) has a serious bug: It
ignores the parameter batch completely; instead, it retrieves rows from
self.plain_resultset, i.e., the Storm ResultSet which does not have yet
a WHERE clause for batching. So, it always returns the memo values for
the first batch. (Or the last batch for "backwards batching")
The problem: The batch contains "only traces" from the sliced result.
StormRangeFactory.getSlice() returns list(sliced_resultset) because the
batching machinery calls somewhere len(slice). This means that the batch
not contain any "raw" result row, so we can't access the raw result rows
of DecoratedResultSets -- but we need the raw result rows to find the
memo values.
(1) We could fix this by caching the raw result sets in
StormRangeFactory.getSlice(), like
self._slices[(size, endpoint_memo, forwards)] = \
self.getSliceFromMemo(...)
and use self._slices in getEndpointMemos() to retrieve the raw data.
Slightly ugly, I think...
(2) We can return the endpoint memos in getSlice(). Here, we still have
access to the raw result.
(3) We could replace the len(sliced) calls in
z3batching.batch._Batch.sliced_list() with something "Storm compatible",
like
try:
l = len(sliced)
except TypeError:
l = sliced.count()
This would allow us to use batch.sliced_list.get_plain_resultset() in
getEndpointMemos() for DecoratedResultSets. Also a bit ugly, I think.
In other words, I prefer (2). What do you think?
Abel
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
