Hello, Julian, I find myself in a similar position. I upgraded into Calcite 1.28 in a certain project. This project had several custom rules, which (due to the rule config refactoring [1], [2], [3]) now use some deprecated elements (e.g. RelRule#Config#EMPTY). Recently I tried to adapt my rules to get rid of the deprecated elements and I stumbled upon the same problem that you mention. The situation will be more serious in 1.29, when these deprecated elements are completely removed. Jacques, thanks for the feedback. I will also take a look at your proposals.
Regards, Ruben [1] https://issues.apache.org/jira/browse/CALCITE-4787 [2] https://issues.apache.org/jira/browse/CALCITE-4825 [3] https://issues.apache.org/jira/browse/CALCITE-4830 On Thu, Dec 2, 2021 at 11:24 PM Julian Hyde <[email protected]> wrote: > Thanks for the prompt reply, Jacques. I’ll explore your suggestions and > let you know what I find. > > > On Dec 2, 2021, at 1:33 PM, Jacques Nadeau <[email protected]> wrote: > > > > Hey Julian, > > > > To me, there are currently three avenues I envisioned for extension > project > > use: > > 1. Use the Immutable project or similar alternatives (e.g. [1]) > > 2. Write a concrete class that implements the declared interface. > > 3. Use a record metaphor appropriate to the environment you're in that > > implements the interface (Record in java 14+, Data class in Kotlin, etc) > > > > There is a fourth option, which is extending Immutable generated > > code. Because Immutables was new in 1.28, I wanted to avoid introducing > new > > surface area directly related to the Immutables compiler/compiled class > and > > thus made all the implementations package private [1]. I felt this was > > safer than introducing these directly but if we feel like that is > something > > we should expose, it would be a relatively straightforward change. Note > > that the current pattern is only producing code for concrete subclasses > of > > RelRule.Config for specific rules, not the generic RelRule.Config which > is > > only an abstract interface. > > > > Given your constraints, I would explore #2 or #3 (and would love to hear > > feedback on #4). > > > > One other question that comes to mind is that is this a pain more in > > specifically the concept of new direct subclasses of RelRule.Config or > > subclasses of other concrete rule config subclasses. > > > > [1] https://github.com/Randgalt/record-builder > > [2] > > > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/CalciteImmutable.java#L30 > > > > On Thu, Dec 2, 2021 at 12:20 PM Julian Hyde <[email protected]> > wrote: > > > >> I’m trying to write a planner rule in a dependent project. (What what > it’s > >> worth, the project is not open source, and is implemented in Kotlin.) I > >> don’t want to make the dependent project depend on the Immutables > library, > >> because that introduces an annotation processor and might destabilize > our > >> build. > >> > >> I need to implement RelRule.Config in order to override the toRule > method > >> to create an instance of my rule. But as RelRule.Config uses > Immutables, it > >> does not have an implementation that I can subclass. > >> > >> Has anyone else run into this problem? > >> > >> Julian > >> > >> > >
