[ https://issues.apache.org/jira/browse/CALCITE-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228875#comment-15228875 ]
Julian Hyde commented on CALCITE-1190: -------------------------------------- Wikipedia has a page on TCK https://en.wikipedia.org/wiki/Technology_Compatibility_Kit but I don't believe that the term is specific to the Java platform. It's just a test suite with inversion of control. Apache Harmony (mentioned in the wikipedia page) is an interesting (and sad) case, because it was a war fought over a TCK. > 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)