getRowsColumnRangeIterator

[sandorw]

Goals (and why):
Adds a new method to tables getRowsColumnRangeIterator that is similar to getRowsColumnRange, except it returns an Iterator instead of a BatchingVisitable.

Implementation Description (bullets):
Mostly modifications to generated tables that are checked in.

Testing (What was existing testing like? What have you done to improve it?):
Copied existing tests using getRowsColumnRange. I didn't want to combine the testing in case any implementation changes in the future, and the additional tests should be cheap. The contract should be the same, so existing tests should cover the functionality.

Concerns (what feedback would you like?):

Where should we start reviewing?:
Skip all the generated files, everything else should be relevant and fairly quick.

Priority (whenever / two weeks / yesterday):

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Added a new method to generated table schemas, getRowsColumnRangeIterator, that returns an iterator for each row rather than a BatchingVisitable.

Check the box to generate changelog(s)

• Generate changelog entry

[felixdesouza]

a better/easier/clearer test would be doing the setup as normal, and then assert in the batching visitable view, and then do the iterator view, and then assert that the contents are the same? at the same time, not too fussed

[sandorw]

yeah, got stuck in this pattern after touching a few tests where it was not appropriate to combine the two

[sandorw]

I consolidated in the few cases where it was safe to do so without making the test harder to understand or where the it was important to the test itself

[sandorw]

Added a few more tests to explicitly cover the case where we do read a result from the row, but only conflict with another writer if we attempt to read past the first result.

[felixdesouza]

Small question about a test, but is likely just misunderstanding, so will approve.