indigophox commented on code in PR #34817:
URL: https://github.com/apache/arrow/pull/34817#discussion_r1170554570
##########
format/FlightSql.proto:
##########
@@ -1842,6 +1842,94 @@ message ActionCancelQueryResult {
CancelResult result = 1;
}
+/*
+ * Request message for the "Close Session" action.
+ */
+message ActionCloseSessionRequest {
Review Comment:
Re: the lower-level helper question, I think the middleware implementation
we were debating whether to include is (a) at the right interface level
(bypassing the middleware interface probably doesn't make a lot of sense, and
it's necessary to use the Flight Server Middleware interface to allow the
handlers to juggle the inbound and particularly outbound session ID cookie
local to the call, and (b) a complete reference as to the required mechanics to
make everything work should anyone feel the need to try to do the same thing
differently.
Re: header support, I'm not 100% sure if you're talking about the session ID
or the options themselves. I am reticent to provide default (part of Arrow vs.
app-defined) support of arbitrary option headers, but as these are explicitly
not part of the session functionality and work via headers that the client
handlers can already access and handle I think supporting that is a no-op. As
to providing headers (instead of full client middleware) as a fallback for
keeping/sharing the session ID across e.g. distributed clients or whatever, the
session ID is already a header (albeit a cookie) so I can simply provide the
accessor we were considering for getting the session ID out of the provided
middleware implementation (probably a subclass with just the extra accessor(s))
and then client apps can do as they please with that data.
--
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]
