launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

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