indigophox commented on code in PR #34817:
URL: https://github.com/apache/arrow/pull/34817#discussion_r1423097465
##########
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;
Review Comment:
> I wonder about the strong typing and how it would actually be used between
a client and server without having both of them know in advance what the type
is?
>
> In the context of URL parsing, if we allow for passing extra options as
query parameters, all of them would be untyped so how the client would be able
to provide them to the server with the correct type?
Very good point here. I think the best behaviour is perhaps to have servers
allow preferred-type-OR-string, and native Flight clients get the benefit of
strongly-typed options, while other e.g. *DBC clients that have an interface
that precludes passing in typed options (e.g. connection string parameters) can
defer that to the server. This should probably also be documented in the
Protocol specification as the preferred practice.
--
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]
