You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Hongze Zhang (JIRA)" <ji...@apache.org> on 2019/04/29 17:15:06 UTC

[jira] [Closed] (CALCITE-1190) Cross-Version Compatibility Test Harness

     [ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hongze Zhang closed CALCITE-1190.
---------------------------------

The issue was resolved but not closed in the given fix version. Closing now.

> 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
>            Priority: Major
>             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
(v7.6.3#76005)