shunping commented on code in PR #30317:
URL: https://github.com/apache/beam/pull/30317#discussion_r1492631642
##########
model/fn-execution/src/main/proto/org/apache/beam/model/fn_execution/v1/beam_fn_api.proto:
##########
@@ -1075,6 +1111,42 @@ message StateClearRequest {}
// A response to clear state.
message StateClearResponse {}
+// A message describes a sort key range [start, end).
+message OrderedListRange {
+ int64 start = 1;
+ int64 end = 2;
+}
+
+// A data entry which is tagged with a sort key.
+message OrderedListEntry {
+ int64 sort_key = 1;
+ bytes data = 2;
+}
+
+// This request will fetch an ordered list with a sort key range. If the
+// timestamp range is not specified, the runner should use [MIN_INT64,
+// MAX_INT64) by default.
+message OrderedListStateGetRequest {
+ bytes continuation_token = 1;
Review Comment:
> comment on continuation token ...
Good idea! I will add that when I revise the code.
> Do we want to require returning the range if there's a continuation token
involved? Or should they be mutually exclusive?
I don't think the range is a hard requirement.
In fact in my simple implementation of the fake client, I put the current
sort key and the current block index into the continuation token:
https://github.com/apache/beam/blob/5d7cd5e2e2e6b966ddb47cd78135b58013622d23/sdks/java/harness/src/test/java/org/apache/beam/fn/harness/state/FakeBeamFnStateClient.java#L228.
In other implementation, you may need the range, but I think it is
implementation-dependent. That's why I hesitate to put a range/sort key as a
separate field when continuation token is present.
I thought the continuation token should allow the runner to uniquely
identify where to find the next block of data. Is that what you mean by
"mutually exclusive"?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscr...@beam.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
