You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Gavin Ray <ra...@gmail.com> on 2021/12/22 14:55:21 UTC
Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?
I am still learning the fundamentals of Calcite's API, and I've found that
there are pre-made schemas
and other utilities meant for testing inside of the Calcite repo.
Unfortunately it seems like a lot of these objects are private, because
they aren't meant to be a part of the public API.
I've taken to copy-pasting entire files to be able to get tests setup in my
own project:
-
https://github.com/GavinRay97/GraphQLCalcite/blob/master/src/main/kotlin/HrClusteredSchemaKotlin.kt
I think it could be valuable to others who aren't developing their code in
the Calcite tree
to be able to use the work that's been put into setting up premade test
items.
Or maybe there is a better way, would appreciate any advice.
Thank you =)
Gavin Ray
Re: Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?
Posted by Vladimir Sitnikov <si...@gmail.com>.
Gavin,
Please check sample schemata in
https://github.com/apache/calcite/tree/7a7b37fc1f4bd2121643539b0fd8e9c4f0f8ed09/testkit/src/main/java/org/apache/calcite/test/schemata
If you find useful schemas, don't hesitate filing a PR to add samples to
/testkit/
Vladimir
Re: Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?
Posted by Michael Mior <mm...@apache.org>.
Thanks Julian for CALCITE-4885! I've avoided trying to do anything
with the notebook repository I created a while back since test
artifacts are no longer published. It would be great to get that up to
date with the latest Calcite version.
--
Michael Mior
mmior@apache.org
Le mer. 22 déc. 2021 à 18:15, Julian Hyde <jh...@gmail.com> a écrit :
>
> Gavin,
>
> I’m working on this in https://issues.apache.org/jira/browse/CALCITE-4885 <https://issues.apache.org/jira/browse/CALCITE-4885>. Take a look at FixtureTest [1] to get an idea of how parser, validator, sql-to-rel or rule tests would look in your project.
>
> My one concern is that once we make our test infrastructure public (as we have already started to with the new ’testkit’ module), people will expect that we follow semantic versioning. But we won’t. Of course semantic versioning is very nice if you are the consumer of a project, but it has a high cost for the project maintainers. Therefore there will be no guarantees of compatibility of the ‘testkit’ module from one release to the next.
>
> Julian
>
> [1] https://github.com/julianhyde/calcite/blob/4885-test-fixtures/testkit/src/test/java/org/apache/calcite/test/FixtureTest.java
>
>
> > On Dec 22, 2021, at 6:55 AM, Gavin Ray <ra...@gmail.com> wrote:
> >
> > I am still learning the fundamentals of Calcite's API, and I've found that
> > there are pre-made schemas
> > and other utilities meant for testing inside of the Calcite repo.
> >
> > Unfortunately it seems like a lot of these objects are private, because
> > they aren't meant to be a part of the public API.
> >
> > I've taken to copy-pasting entire files to be able to get tests setup in my
> > own project:
> > -
> > https://github.com/GavinRay97/GraphQLCalcite/blob/master/src/main/kotlin/HrClusteredSchemaKotlin.kt
> >
> > I think it could be valuable to others who aren't developing their code in
> > the Calcite tree
> > to be able to use the work that's been put into setting up premade test
> > items.
> >
> > Or maybe there is a better way, would appreciate any advice.
> >
> > Thank you =)
> > Gavin Ray
>
Re: Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?
Posted by Gavin Ray <ra...@gmail.com>.
Julian, this is awesome to hear -- and thank you for the pointers to this
"FixtureTest" file, I hadn't found that one yet =)
A couple of the helper methods and patterns seem particularly useful, like
this one for setting everything up with a particular test schema:
final SchemaPlus rootSchema = Frameworks.createRootSchema(true);
final FrameworkConfig config = Frameworks.newConfigBuilder()
.defaultSchema(
CalciteAssert.addSchema(rootSchema, CalciteAssert.SchemaSpec.HR
))
.build();
And this, which takes a SQL string and executes + dumps various stages of a
plan:
void executeQuery(FrameworkConfig config, String query, boolean debug)
------------
> "My one concern is that once we make our test infrastructure public (as
we have already started to with the new ’testkit’ module), people will
expect that we follow semantic versioning."
I could see that being an issue for sure.
My view is "something is better than nothing!" so I'm happy to use whatever
I can get.
On that note, I'm trying to keep notes on "Here's what you can use to get
testing/mocking + productive quickly with Calcite", in the hopes of
contributing some more documentation in that area.
Mostly I've been reading a lot of test code and searching the Calcite repo
for uses of whatever method.
Outside of the BOSS tutorial and the Calcite Meetup video, there's not a
ton of beginner content.
Calcite is really, really cool. It's just a matter of figuring out "What
the heck is this thing -- and how do I use it?!" 😅
On Wed, Dec 22, 2021 at 6:15 PM Julian Hyde <jh...@gmail.com> wrote:
> Gavin,
>
> I’m working on this in https://issues.apache.org/jira/browse/CALCITE-4885
> <https://issues.apache.org/jira/browse/CALCITE-4885>. Take a look at
> FixtureTest [1] to get an idea of how parser, validator, sql-to-rel or rule
> tests would look in your project.
>
> My one concern is that once we make our test infrastructure public (as we
> have already started to with the new ’testkit’ module), people will expect
> that we follow semantic versioning. But we won’t. Of course semantic
> versioning is very nice if you are the consumer of a project, but it has a
> high cost for the project maintainers. Therefore there will be no
> guarantees of compatibility of the ‘testkit’ module from one release to the
> next.
>
> Julian
>
> [1]
> https://github.com/julianhyde/calcite/blob/4885-test-fixtures/testkit/src/test/java/org/apache/calcite/test/FixtureTest.java
>
>
> > On Dec 22, 2021, at 6:55 AM, Gavin Ray <ra...@gmail.com> wrote:
> >
> > I am still learning the fundamentals of Calcite's API, and I've found
> that
> > there are pre-made schemas
> > and other utilities meant for testing inside of the Calcite repo.
> >
> > Unfortunately it seems like a lot of these objects are private, because
> > they aren't meant to be a part of the public API.
> >
> > I've taken to copy-pasting entire files to be able to get tests setup in
> my
> > own project:
> > -
> >
> https://github.com/GavinRay97/GraphQLCalcite/blob/master/src/main/kotlin/HrClusteredSchemaKotlin.kt
> >
> > I think it could be valuable to others who aren't developing their code
> in
> > the Calcite tree
> > to be able to use the work that's been put into setting up premade test
> > items.
> >
> > Or maybe there is a better way, would appreciate any advice.
> >
> > Thank you =)
> > Gavin Ray
>
>
Re: Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?
Posted by Julian Hyde <jh...@gmail.com>.
Gavin,
I’m working on this in https://issues.apache.org/jira/browse/CALCITE-4885 <https://issues.apache.org/jira/browse/CALCITE-4885>. Take a look at FixtureTest [1] to get an idea of how parser, validator, sql-to-rel or rule tests would look in your project.
My one concern is that once we make our test infrastructure public (as we have already started to with the new ’testkit’ module), people will expect that we follow semantic versioning. But we won’t. Of course semantic versioning is very nice if you are the consumer of a project, but it has a high cost for the project maintainers. Therefore there will be no guarantees of compatibility of the ‘testkit’ module from one release to the next.
Julian
[1] https://github.com/julianhyde/calcite/blob/4885-test-fixtures/testkit/src/test/java/org/apache/calcite/test/FixtureTest.java
> On Dec 22, 2021, at 6:55 AM, Gavin Ray <ra...@gmail.com> wrote:
>
> I am still learning the fundamentals of Calcite's API, and I've found that
> there are pre-made schemas
> and other utilities meant for testing inside of the Calcite repo.
>
> Unfortunately it seems like a lot of these objects are private, because
> they aren't meant to be a part of the public API.
>
> I've taken to copy-pasting entire files to be able to get tests setup in my
> own project:
> -
> https://github.com/GavinRay97/GraphQLCalcite/blob/master/src/main/kotlin/HrClusteredSchemaKotlin.kt
>
> I think it could be valuable to others who aren't developing their code in
> the Calcite tree
> to be able to use the work that's been put into setting up premade test
> items.
>
> Or maybe there is a better way, would appreciate any advice.
>
> Thank you =)
> Gavin Ray