[jira] [Commented] (CALCITE-663) Add CreateConnectionRequest and protocol version to Avatica protocol

["Nick Dimiduk (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481581#comment-14481581 ] 

Nick Dimiduk commented on CALCITE-663:
--------------------------------------

bq. CreateConnectionRequest.requestedProtocolType

This implies perhaps there will be special code depending on the protocol type? (I'm thinking of the if(json) block we've discussed previously). Can we distinguish between wire protocol (http) and message encoding (json)? Can we include this in a header or some other envelope mechanism? Does it make sense to call it "provided", "used", or simply "protocol" -- it's not that it was requested, it's what was sent.

bq. CreateConnectionRequest.requestedProtocolVersion

Would it be better to have a means for feature inspection? A bit-field representing method names that are supported by the server, for instance.

bq. CreateConnectionRequest.driverName / driverVersion

Informational, I suppose. Like a user agent. Sure.

One goal we have is to allow for session-less utilization of the query server. Meaning, a client should be able to send the complete context for a request to an previously unknown server and it should respond with a result set. This allows us to put a pool of Avatica Servers behind a load balancer. We don't have this yet today, but nothing today precludes us from getting there. To support taking action on these details, we would need to include these message components in every such method.

> Add CreateConnectionRequest and protocol version to Avatica protocol
> --------------------------------------------------------------------
>
>                 Key: CALCITE-663
>                 URL: https://issues.apache.org/jira/browse/CALCITE-663
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>              Labels: avatica
>
> Add protocol version to Avatica protocol, to allow forwards and backwards compatibility.
> The first request should be a CreateConnectionRequest, let's add the attributes there. I propose:
> * CreateConnectionRequest.requestedProtocolType e.g. "json"
> * CreateConnectionRequest.requestedProtocolVersion e.g. "1.2.0"
> * CreateConnectionRequest.driverVersion
> * CreateConnectionRequest.driverName e.g. "org.apache.calcite.avatica.remote.Driver"
> * CreateConnectionResponse.protocolType
> * CreateConnectionResponse.protocolVersion
> * CreateConnectionResponse.databaseVersion
> There is currently no CreateConnectionRequest.
> Certain servers configurations would continue to allow connections to be implicitly created, but using an explicit CreateConnectionRequest would always be possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)