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 <jhyde.apa...@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 <ray.gavi...@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
>
>

Reply via email to