[
https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228679#comment-15228679
]
Josh Elser commented on CALCITE-1190:
-------------------------------------
Actually, maybe a good first stab is to just implement an HSQLDB avatica server
impl that we can provide avatica jars at runtime? Same approach, but we
wouldn't have to depend on Phoenix/Drill/etc to wire it up.
> Cross-Version Compatibility Test Harness
> ----------------------------------------
>
> Key: CALCITE-1190
> URL: https://issues.apache.org/jira/browse/CALCITE-1190
> Project: Calcite
> Issue Type: Test
> Components: avatica
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: avatica-1.8.0
>
>
> One thing that the Protobuf serialization aimed to provide was a library
> which provides us the tools to make Avatica compatible across versions.
> However, Protobuf is just a tool and the developers can still misuse protobuf
> in such a way that breaks compatibility across versions. Not to mention,
> compatibility isn't even remotely certain without any tests.
> Because of Avatica's position as a library less than a product, we have to
> defer some logic to the concrete product being tested (e.g. Phoenix or
> Drill). I'm thinking something like the following:
> The user provides pairs of client and server "definitions" for a given
> version of compatibility. This would include some version of Avatica and some
> backing database. For example, Avatica-1.7.1 and Phoenix-4.7.0 or
> Avatica-1.8.0-SNAPSHOT and HSQLDB-2.3.1.
> The client half would be some template for the appropriate JDBC url to use
> (sans the URL to the Avatica server) and a JAR file containing the necessary
> classes to run the j.s.Driver. The server half would just be a URL to the
> Avatica server instance.
> The test harness itself can provide the logic to test the remote driver
> against the other servers, enumerating the possible combinations of
> client-server communication. Starting the server for each version to test is
> likely too difficult to automate well given the unknown of what the server
> will be, so that will be left as a prerequisite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
