[
https://issues.apache.org/jira/browse/CALCITE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971676#comment-14971676
]
Josh Elser commented on CALCITE-663:
------------------------------------
bq. Is the protocol version solved
As the JSON currently stands, I don't see anything gained from including the
client version except for diagnostic purposes (e.g. client of 1.4.0 fails to
talk to server 1.5.0). For protobuf, we could also benefit from the same
diagnostics, but the serialization itself better insulates us from these kinds
of issues.
IMO, the diagnostic case alone is nice enough as it would help make debugging
user problems easier.
> Add protocol version to Avatica protocol
> ----------------------------------------
>
> Key: CALCITE-663
> URL: https://issues.apache.org/jira/browse/CALCITE-663
> Project: Calcite
> Issue Type: Bug
> Components: avatica
> 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.
> *Edit (Julian Hyde, 2015-10-24)*: No longer true. OpenConnectionRequest was
> implemented in CALCITE-912.
> 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)
