indigophox commented on code in PR #34817:
URL: https://github.com/apache/arrow/pull/34817#discussion_r1418125513
##########
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.
+ */
+message SetSessionOptionsRequest {
+ map<string, SessionOptionValue> session_options = 1;
+}
+
+/*
+ * EXPERIMENTAL: The results (individually) of setting a set of session
options.
+ */
+message SetSessionOptionsResult {
+ enum Status {
+ // The status of setting the option is unknown. Servers should avoid using
+ // this value (send a NOT_FOUND error if the requested query is
+ // not known). Clients can retry the request.
+ SET_SESSION_OPTION_RESULT_UNSPECIFIED = 0;
+ // The session option setting completed successfully.
+ SET_SESSION_OPTION_RESULT_OK = 1;
+ // The given session option name was an alias for another option name.
+ SET_SESSION_OPTION_RESULT_OK_MAPPED = 2;
+ // The given session option name is invalid.
+ SET_SESSION_OPTION_RESULT_INVALID_NAME = 3;
+ // The session option value is invalid.
+ SET_SESSION_OPTION_RESULT_INVALID_VALUE = 4;
+ // The session option cannot be set.
+ SET_SESSION_OPTION_RESULT_ERROR = 5;
+ }
+
+ message Result {
+ Status status = 1;
+ }
+
+ map<string, Result> results = 1;
Review Comment:
> > Would it be reasonable for the "default" to be success, and just _only_
report failures/errors, and the client can assume any option they set which is
not reported in the response was successful?
>
> I would presumably have to eliminate the OK_MAPPED status, but yes this
would keep the parsing consistent with the request structure AND eliminate a
lot of work for the client by reducing the MVP to checking the length of the
response map.
@pitrou does this option satisfy your concerns here, as it seems to me to?
--
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]
