Josh Elser created CALCITE-1190:
-----------------------------------
Summary: 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)
