-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CALCITE-5529] Improve dialect tests, part 1: check each query against a reference dialect #4206
base: main
Are you sure you want to change the base?
Conversation
Require that newlines in Java string literals are at the end of a fragment. This forces developers to break string literals over several lines, to match the contents of the literals, and helps make long SQL queries and results easier to read and maintain. Disallow '.' at the end of a line of Java code. (If a chain of method calls or field references is broken over multiple lines, each '.' should be at the start of or in the middle of a line.)
…t a reference dialect Create class RelToSqlFixture (was inner class RelToSqlConverterTest.Sql). This fixture has a list of dialects for which the test is enabled, and a reference dialect (currently always Calcite). When the test calls 'done()' on the fixture, the fixture checks the query against the reference dialect. In future, it will also execute the query against each enabled dialect. To ensure that each test remembers to call 'done'()', add a 'token pool' to the test framework. If a token has been opened but not closed, the framework prints the call stack of the 'open' call and fails the test. Add enum DialectCode, which defines the dialects (or dialect configurations) that are possible to test. Adding a DialectCode has a cost (e.g. a bunch of new Quidem recording files) so we should not add one without a good reason. After this change, all queries succeed against the reference dialect (Calcite). A few cases are disabled due to bugs; we should fix these bugs and enable the tests. This is just part 1. Part 2 will be to get the tests to succeed against another dialect (probably a local instance of Postgres). Part 3 will be to use a Quidem recording rather than a live Postgres instance. Part 4 will be to enable this framework for other tests (e.g. SqlOperatorTest). Close apache#4206
d12029c
to
d7e1d02
Compare
|
|
final Properties info = new Properties(); | ||
// Hive for RLIKE, Postgres for ILIKE, Spark for EXISTS, etc. | ||
info.put(CalciteConnectionProperty.FUN.name(), | ||
"standard,postgresql,bigquery,hive,spark"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small question: why those libraries are chosen?
info.put(CalciteConnectionProperty.SCHEMA.name(), | ||
schemaSpec.schemaName); | ||
info.put(CalciteConnectionProperty.CONFORMANCE.name(), | ||
SqlConformanceEnum.LENIENT.name()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we use LENIENT rather than DEFAULT?
return new HiveSqlDialect(HiveSqlDialect.DEFAULT_CONTEXT | ||
.withDatabaseMajorVersion(majorVersion) | ||
.withDatabaseMinorVersion(minorVersion) | ||
.withNullCollation(NullCollation.LOW)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DEFAULT_CONTEXT in HiveSqlDialect already has the NullCollation.LOW
.
return dialect(JETHRO); | ||
} | ||
|
||
RelToSqlFixture withMssql() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need other withMssql for different versions?
* Incorrect return type for BigQuery TRUNC functions </a>. | ||
* cases such as | ||
* <a href="https://issues.apache.org/jira/browse/CALCITE-5757">[CALCITE-5757] | ||
* Incorrect return type for BigQuery TRUNC functions</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
</a>. */
|
||
/** Throws if not all fixtures have been released. */ | ||
public void assertEmpty() { | ||
int size = map.size(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Pool able to handle this situation:
- when calling
map.size()
we get 0 - before calling
map.isEmpty()
, a token is added - so the pool is not empty but with size 0
? sql | ||
: dialect(testConfig.refDialectCode).exec(); | ||
switch (phase) { | ||
case PREPARE: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's phase PARSE for and do we need to handle it here?
I will test it locally |
See CALCITE-5529.