db: paginated sequence for temporal KV API #2186
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces support for a hand-crafted paginated sequence of values to be used in the definition of
temporal KV
API endpoints. Such abstraction allows user code to navigate a paginated contiguous sequence of values without bothering about pagination at call site.If performance measurements in standalone mode (i.e. direct KV client) will show significant overhead caused by this approach, we can relax this requirement to hide pagination at call site and try to obtain faster code.
Design Alternatives
We're going to use this abstraction for both direct and gRPC KV client implementations and we cannot block the coroutine scheduler in gRPC case, so we do need a common asynchronous interface definition. This requirement (which could be challenged if performance results are not satisfactory) excludes usage of a C++ iterator.
Hence, I have considered the following alternative options:
std::generator
reference implementation: not feasible because it does not allow usage ofco_await
within the generator coroutinecobalt
implementation, which is based on and is compatible with Asio, but it would require to add a new dependency and using other companioncobalt
abstractions just for one class: this seems too much.Notes
Evaluating usage of Cobalt could be interesting as a research sub-project, so I've opened #2185