[
https://issues.apache.org/jira/browse/CALCITE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372121#comment-16372121
]
Piotr Bojko commented on CALCITE-2088:
--------------------------------------
On top of current master e2e tests have started to fail:
{code:java}
> java.lang.AssertionError: Type mismatch:
> rel rowtype:
> RecordType(INTEGER GENREID, INTEGER NOT NULL ID) NOT NULL
> equivRel rowtype:
> RecordType(INTEGER GENREID) NOT NULL
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at org.apache.calcite.plan.RelOptUtil.equal(RelOptUtil.java:1864)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:855)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.convert.ConverterRule.onMatch(ConverterRule.java:129)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:319)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:781)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> at net.hydromatic.quidem.Quidem$CheckResultCommand.execute(Quidem.java:830)
> at net.hydromatic.quidem.Quidem$CompositeCommand.execute(Quidem.java:1450)
> at net.hydromatic.quidem.Quidem.execute(Quidem.java:197)
> at org.apache.calcite.test.QuidemTest.checkRun(QuidemTest.java:152)
> at org.apache.calcite.test.QuidemTest.test(QuidemTest.java:209)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMeth{code}
> More complex end2end tests in Calcite Plus module
> -------------------------------------------------
>
> Key: CALCITE-2088
> URL: https://issues.apache.org/jira/browse/CALCITE-2088
> Project: Calcite
> Issue Type: Improvement
> Affects Versions: 1.16.0
> Reporter: Piotr Bojko
> Assignee: Piotr Bojko
> Priority: Major
>
> As in following correspondence - we would like to have more tests with more
> complexity. This should lead to lower regressions.
> {quote}
> Yes, please do.
> On Dec 8, 2017, at 7:13 AM, [email protected] wrote:
>
> I've taken a look into quidem.
>
> I will log jira for that and assign it to myself, ok?
>
> On Tue, Dec 5, 2017, 22:26 Julian Hyde <[email protected]> wrote:
>
> More tests are always welcome.
>
> I would be wary of adding a new approach (assertj-db). Over time we end up
> with as many approaches as there are contributors, and so the code becomes
> hard to maintain. Consider using quidem (see QuidemTest and various .iq
> files in the code base); it combines assertion-based testing with the
> simplicity of script-based tests.
>
> This could be added to the “plus” module, where we don’t mind extra
> dependencies, and don’t mind if the test suite takes a long time.
>
> Julian
>
>
> On Dec 2, 2017, at 3:40 PM, [email protected] wrote:
>
> Hello fellow calcite dev team,
>
> I am building a database with use of calcite framework and decided that
> instead of simple unit tests I will go only with integration tests. This
> is
> due the fact that my code only glues the calcite with data and configures
> the whole thing decorating with web api and jdbc access (with avatica ;)
> ).
>
> I have some problems with calcite, possible bugs - some of them in apache
> jira for calcite logged already. Those problem are visible through my
> tests.
>
> And with that in mind I have an idea for a new maven artifact for
> calcite -
> end to end tests for an example h2 database. Database could have some
> tables with data - maybe 100k rows in all tables. Tests with assertj and
> its derivatives, something like I've done in my project - see the
> pastebin
> https://pastebin.com/raw/mevih4k6 .
>
> Such test set can help with lowering regressions establishing a common
> ground for talking about the calcite behaviour on specific cases (which
> can
> be described through end2end tests).
>
> The tech under such maven artifact can be pretty simple:
>
> - h2 as a data source, maybe some other
> - one properly complicated json calcite schema
> - some tech for populating h2 with data (just for having data with some
> descriptive language, not a binary format)
> - assertj-db for DSL in tests
>
> What do You think?
>
> Cheers,
> Pete
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
