Francis>I remembered joining this list a few years back then Francis>- Calcite - SQL engine used to build the SQL part of your database.
The things is "apache/calcite" is tons of features as in "thing that converts SQL to MongoDB" or "thing that executes SQL queries over InnoDB data files", or "thing that validates SQL", or "linq4j". There are lots of features, and there are lots of artifacts. The set of modules is not perfect, and there are cases when somebody needs "just optimizer", and there are valid reasons to hate "Enumerable" or "dynamic bytecode generation". However, it looks like having Avatica in the same repository does not hurt much as long as the other features do not impact Avatica features much. Francis>Each should be able to stand up on its own and have its own independent release schedule Having a different release schedule means we must support at least two different Avatica versions in Calcite. That adds overhead on Calcite development as we have to make test code to account for different Avatica. Francis>I've seen PRs that need to touch both repositories for Francis>a change and it seems like a code smell to me Even though testing the "exact exception message" at Calcite side looks weird, it is important to test how the exception would look like for the end-user, so there must be an integration test that ensures Avatica produces proper exceptions, and Calcite does not make them bad (e.g. by ignoring the message). Francis>own independent release schedule For now, Calcite Avatica is stuck with Gradle 6 since it uses "dependencies between test source sets". In other words, test classes in calcite-avatica/server depend on test classes in calcite-avatica/core. That is an anti-pattern, and the resolution is to move the common test classes into a proper artifact with its metadata and dependencies. This is something I fixed in Calcite in https://issues.apache.org/jira/browse/CALCITE-4821 Here's the question: who would do the relevant work for calcite-avatica? Vladimir
