Xiao-zhen-Liu commented on code in PR #5900:
URL: https://github.com/apache/texera/pull/5900#discussion_r3493452996
##########
amber/src/main/python/core/models/state.py:
##########
@@ -25,13 +25,41 @@
class State(dict):
CONTENT = "content"
- SCHEMA = Schema(raw_schema={CONTENT: "STRING"})
+ # Loop-control bookkeeping owned by the worker runtime, NOT user state --
it
+ # never appears in the content JSON. In memory it rides on the StateFrame
+ # envelope; it is materialized/serialized as its own column (parallel to
+ # content) by to_tuple(...). from_tuple() returns the bare State; callers
+ # that need these values read the corresponding columns off the tuple.
+ LOOP_COUNTER = "loop_counter"
+ LOOP_START_ID = "loop_start_id"
+ LOOP_START_STATE_URI = "loop_start_state_uri"
Review Comment:
Thanks, that's clear. Agreed the URI isn't derivable from `loop_start_id` at
the worker, since it's the physical input-port URI of the operator feeding
LoopStart. Not a blocker. One thing to consider in the loop PR: the controller
allocates these port URIs and knows the topology, so it could resolve the write
location from `loop_start_id` itself and keep the URI out of the saved state.
Worth a look there; fine as-is here.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
