[
https://issues.apache.org/jira/browse/CALCITE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418801#comment-17418801
]
Jacques Nadeau commented on CALCITE-4787:
-----------------------------------------
Thinking more about this, I think it is possible to continue to support as on
the EMPTY derived-bean alone and throw for any other bean. I think this would
minimize the disruption and allow a few releases to mark this usage as
deprecated before removing. What wouldn't be possible: using as() on a rule
config that was based on immutables.
Basically, we'd maintain the ability to use ImmutableBeans functionality as
exposed directly and through the RelRule.Config.As call. In steps, all Calcite
maintained rules could move to immutables. So some instances may be Immutables
based and some may be ImmutableBeans based (both using the same iface). The one
thing that would no longer be supported would be an as() call on a Immutables
based configuration but I think that is okay.
As a test, these changes should eliminate any required changes in the Hive code
based above.
The one constraint that would exist (be breaking) is you could no longer do a
"as" derivation from an immutables-based config. For example, right now you
could theoretically derive from
[this|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/JoinProjectTransposeRule.java#L383]
config instance, declare a subclass and then use as() to downcast. Wit this
change that would no longer be possible I think this would be an acceptable
pattern change and allow most (all) external project changes to be handled in
traditional "few release" deprecation strategy. This is due to the fact that
the pattern I see people using is typically EMPTY as a starting point, not an
intermediate proxied config. That's also what's used in 99% of the Calcite code
(e.g. Cassandra rule configs). The only place that I've seen so far that
doesn't fit this pattern is the materialized view rule config hierarchy which
has 3 levels of derivation.
> Evaluate use of Immutables instead of ImmutableBeans
> ----------------------------------------------------
>
> Key: CALCITE-4787
> URL: https://issues.apache.org/jira/browse/CALCITE-4787
> Project: Calcite
> Issue Type: Improvement
> Reporter: Jacques Nadeau
> Assignee: Jacques Nadeau
> Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> In the creation of CALCITE-3328, [Immutables|https://immutables.github.io/]
> was discussed as an alternative to a custom implementation. This ticket is to
> evaluate the impact to the codebase of changing. Ideally, introduction of
> immutables would both add flexibility and reduce the amount of code
> associated with these classes.
> Immutables works via annotation processor which means that it is should be
> relatively seamless to build systems and IDEs.
> The switch would also make it easier to work with these objects types in the
> context of aot compilation tools like GraalVM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
