indigophox commented on code in PR #34817:
URL: https://github.com/apache/arrow/pull/34817#discussion_r1410044812
##########
format/Flight.proto:
##########
@@ -525,3 +525,108 @@ message FlightData {
message PutResult {
bytes app_metadata = 1;
}
+
+/*
+ * EXPERIMENTAL: Union of possible value types for a Session Option to be set
to.
+ */
+message SessionOptionValue {
+ message StringListValue {
+ repeated string values = 1;
+ }
+
+ oneof option_value {
+ string string_value = 1;
+ bool bool_value = 2;
+ sfixed32 int32_value = 3;
+ sfixed64 int64_value = 4;
+ float float_value = 5;
+ double double_value = 6;
+ StringListValue string_list_value = 7;
+ }
+}
+
+/*
+ * EXPERIMENTAL: A request to set session options for an existing or new
(implicit)
+ * server session.
+ *
+ * Sessions are persisted and referenced via RFC 6265 HTTP cookies, canonically
+ * 'arrow_flight_session_id', although implementations may freely choose their
own name.
Review Comment:
> Hmm... I'm not sure I understand: what does cookies have to do with those
protobuf declarations?
Cookies are used to persist the session across otherwise stateless
Flight/Flight SQL calls.
##########
format/Flight.proto:
##########
@@ -525,3 +525,108 @@ message FlightData {
message PutResult {
bytes app_metadata = 1;
}
+
+/*
+ * EXPERIMENTAL: Union of possible value types for a Session Option to be set
to.
+ */
+message SessionOptionValue {
+ message StringListValue {
+ repeated string values = 1;
+ }
+
+ oneof option_value {
+ string string_value = 1;
+ bool bool_value = 2;
+ sfixed32 int32_value = 3;
+ sfixed64 int64_value = 4;
+ float float_value = 5;
+ double double_value = 6;
+ StringListValue string_list_value = 7;
+ }
+}
+
+/*
+ * EXPERIMENTAL: A request to set session options for an existing or new
(implicit)
+ * server session.
+ *
+ * Sessions are persisted and referenced via RFC 6265 HTTP cookies, canonically
+ * 'arrow_flight_session_id', although implementations may freely choose their
own name.
Review Comment:
> Also, since this references HTTP, how does this translate to e.g. the UCX
backend?
Looking at UCX, its docs are particularly sparse. The documentation here
can be reworded: Does UCX have its own "State Management Mechanism" as it
were, to persist such things across its individual UCP "calls", which we could
generalize the wording here to capture?
--
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...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
