Re: Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?

2021-12-28 Thread Michael Mior
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
mm...@apache.org

Le mer. 22 déc. 2021 à 18:15, Julian Hyde  a écrit :
>
> Gavin,
>
> I’m working on this in 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  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?

2021-12-22 Thread Gavin Ray
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  wrote:

> Gavin,
>
> I’m working on this in 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  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?

2021-12-22 Thread Julian Hyde
Gavin,

I’m working on this in 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  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?

2021-12-22 Thread Vladimir Sitnikov
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


Why not make the "test" namespace public, or move to a separate Maven module that main pulls in as a "testOnly" dependency?

2021-12-22 Thread Gavin Ray
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