indigophox commented on code in PR #34817:
URL: https://github.com/apache/arrow/pull/34817#discussion_r1165044647
##########
format/FlightSql.proto:
##########
@@ -1842,6 +1842,94 @@ message ActionCancelQueryResult {
CancelResult result = 1;
}
+/*
+ * Request message for the "Close Session" action.
+ */
+message ActionCloseSessionRequest {
Review Comment:
I'll try this a little differently as I know I've been taking about
nitty-gritty specifics and maybe missing some big-picture coherence.
There is definitely no magic client app code required for this, it becomes a
single call for one or more session parameters unless one wants to update them.
Server-side, we were on the fence (mostly considering previously-expressed
concerns about more Arrow code to maintain) but if you don't mind the bit of
extra helper module code we can definitely implement and provide a baseline
server middleware for this. Fundamentally the server generates the session
identifier initially (on the first SetSessionOptions call, presumably sent
without any session ID cookie header.
The header functionality, after some earlier redesign, has ended up being
something that we're really only looking at IF an application developer needs
to have some equivalent functionality baked into an app they've locked to a
legacy version of Arrow for whatever reason. Otherwise there is no reason for
the header fallback under any circumstances with up-to-date Arrow versions.
Therefore this is something that's just going to be suggested as a legacy
implementation option for use with stale Arrow versions.
On to the bigger picture, the actual operation flow is roughly like
so—hopefully this provides some clarity:
* Client is initialized—with ClientCookieMiddleware or a custom
alternative—and connects to server
* Client issues a SetSessionOptions DoAction with whatever session
parameters, and no session identifier cookie header
* Server handler queries the call-local middleware instance which is aware
that no session identifier was specified, and therefore returns a
newly-initlaized session identifier.
* Server handler pushes the options down into session middleware, and
assuming that is successful then returns success status(es) for the applicable
options being set, along with the Set-Cookie header containing the session
identifier
* The Flight SQL session proceeds as normal, with the ClientCookieMiddleware
handling the session persistence.
--
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]
