[jira] [Created] (CALCITE-3330) propagateCostImprovements() could result in stack overflow
Xiening Dai created CALCITE-3330: Summary: propagateCostImprovements() could result in stack overflow Key: CALCITE-3330 URL: https://issues.apache.org/jira/browse/CALCITE-3330 Project: Calcite Issue Type: Bug Reporter: Xiening Dai Assignee: Xiening Dai Current implementation uses depth first approach for propagating cost improvements to parent rel nodes. This could lead to stack overflow if the rel node hierarchy is very deep. Suggest use breath first approach for cost propagation. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-2166) Cumulative cost of RelSubset.best RelNode is increased after calling RelSubset.propagateCostImprovements() for input RelNodes
[
https://issues.apache.org/jira/browse/CALCITE-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925043#comment-16925043
]
Danny Chan commented on CALCITE-2166:
-
Thanks [~xndai],
Well, i think there are 2 cases that option 1 & 2 can not fix up the problem
perfectly:
# one rel may belongs to multi RelSubSet, but because we alway use the DP
first search algorithm to update parents of one RelSubSet, the other RelSubSet
may also be affected.
# The plan may be a DAG, one rel may have multiple parents.
I have reviewed your PR, it seems that you choose the #2 proposal, not #1, i
see you add a for loop in each layer of the DP search, can you give a
performance test about how much overhead the patch has introduced ?
Because #1 and #2 are both not perfect fix, we may need to choose #1 while #2
has some overhead but not significant improvement.
PS: i'm still a little skeptical about whether this patch do better or worse,
just like Julian said, with CALCITE-2018, we just comes from a metadata
breaking state to another one.
> Cumulative cost of RelSubset.best RelNode is increased after calling
> RelSubset.propagateCostImprovements() for input RelNodes
> -
>
> Key: CALCITE-2166
> URL: https://issues.apache.org/jira/browse/CALCITE-2166
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Danny Chan
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> After calling {{RelSubset.propagateCostImprovements()}} cumulative cost of
> {{RelSubset.best}} {{RelNode}} may be increased due to the increase of the
> non-cumulative cost caused by changing of input best {{RelNode}}.
> To observe this issue, add this code:
> {code:java}
> if (subset.best != null) {
> RelOptCost bestCost = getCost(subset.best,
> RelMetadataQuery.instance());
> if (!subset.bestCost.equals(bestCost)) {
> throw new AssertionError(
> "relSubset [" + subset.getDescription()
> + "] has wrong best cost "
> + subset.bestCost + ". Correct cost is " + bestCost);
> }
> }
> {code}
> into {{VolcanoPlanner.validate()}} method (line 907).
> List of unit tests which fail with this check:
> {noformat}
> Failed tests:
>
> MaterializationTest.testJoinMaterializationUKFK9:1823->checkMaterialize:198->checkMaterialize:205->checkThatMaterialize:233
> relSubset [rel#226287:Subset#8.ENUMERABLE.[]] has wrong best cost {221.5
> rows, 128.25 cpu, 0.0 io}. Correct cost is {233.0 rows, 178.0 cpu, 0.0 io}
> ScannableTableTest.testPFPushDownProjectFilterAggregateNested:279 relSubset
> [rel#12950:Subset#5.ENUMERABLE.[]] has wrong best cost {63.8 rows, 62.308
> cpu, 0.0 io}. Correct cost is {70.4 rows, 60.404 cpu, 0.0 io}
> ScannableTableTest.testPFTableRefusesFilterCooperative:221 relSubset
> [rel#13382:Subset#2.ENUMERABLE.[]] has wrong best cost {81.0 rows, 181.01
> cpu, 0.0 io}. Correct cost is {150.5 rows, 250.505 cpu, 0.0 io}
> ScannableTableTest.testProjectableFilterableCooperative:148 relSubset
> [rel#13611:Subset#2.ENUMERABLE.[]] has wrong best cost {81.0 rows, 181.01
> cpu, 0.0 io}. Correct cost is {150.5 rows, 250.505 cpu, 0.0 io}
> ScannableTableTest.testProjectableFilterableNonCooperative:165 relSubset
> [rel#13754:Subset#2.ENUMERABLE.[]] has wrong best cost {81.0 rows, 181.01
> cpu, 0.0 io}. Correct cost is {150.5 rows, 250.505 cpu, 0.0 io}
> FrameworksTest.testUpdate:336->executeQuery:367 relSubset
> [rel#22533:Subset#2.ENUMERABLE.any] has wrong best cost {19.5 rows, 37.75
> cpu, 0.0 io}. Correct cost is {22.575 rows, 52.58 cpu, 0.0 io}
> {noformat}
> For the test {{MaterializationTest.testJoinMaterializationUKFK9}} initial
> best plan was:
> {noformat}
> EnumerableProject(empid0=[$5], empid00=[$5], deptno0=[$7]): rowcount = 15.0,
> cumulative cost = {15.0 rows, 45.0 cpu, 0.0 io}, id = 3989
> EnumerableJoin(subset=[rel#3988:Subset#34.ENUMERABLE.[]], condition=[=($1,
> $7)], joinType=[inner]): rowcount = 15.0, cumulative cost = {116.0 rows, 0.0
> cpu, 0.0 io}, id = 4797
> EnumerableFilter(subset=[rel#4274:Subset#47.ENUMERABLE.[0]],
> condition=[=(CAST($2):VARCHAR CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary", 'Bill')]): rowcount = 1.0, cumulative cost = {1.0
> rows, 1.0 cpu, 0.0 io}, id = 16522
> EnumerableTableScan(subset=[rel#158:Subset#11.ENUMERABLE.[0]],
> table=[[hr, m0]]): rowcount = 1.0, cumulative cost = {0.0 rows, 1.0 cpu, 0.0
> io}, id = 79
> EnumerableTableScan(subset=[rel#115:Subset#5.ENUMERABLE.[]], table=[[hr,
>
[jira] [Commented] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925002#comment-16925002
]
Andrei Sereda commented on CALCITE-3328:
I see that Stephen Colebourne already mentions Immutables.
You want it to be based on reflection not codegen-ed ?
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925000#comment-16925000
]
Andrei Sereda commented on CALCITE-3328:
There are quite a few libraries which do it at compile time :
1. [Immutables|http://immutables.github.io/]
2. [FreeBuilder|https://freebuilder.inferred.org/]
3.
[AutoValue|https://github.com/google/auto/blob/master/value/userguide/index.md]
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forward Xu reassigned CALCITE-3329: --- Assignee: Forward Xu > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Implement osquery command for OS adapter, Achieve similar features of > FaceBook's osquery. E.g: > select * from os_version; > select * from system_info; > select * from mounts; > select * from interface_addresses > select * from memory_info; > select * from interface_addresses; > select cpu_info.* from cpu_info; -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forward Xu updated CALCITE-3329: Description: Implement osquery command for OS adapter, Achieve similar features of FaceBook's osquery. E.g: select * from os_version; select * from system_info; select * from mounts; select * from interface_addresses select * from memory_info; select * from interface_addresses; select cpu_info.* from cpu_info; was: Implement osquery command for OS adapter, Achieve similar features of FaceBook's osquery. E.g: select * from os_version; select * from system_info; select * from mounts; select * from interface_addresses select * from memory_info; SELECT * FROM interface_addresses; select cpu_info.* from cpu_info > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Implement osquery command for OS adapter, Achieve similar features of > FaceBook's osquery. E.g: > select * from os_version; > select * from system_info; > select * from mounts; > select * from interface_addresses > select * from memory_info; > select * from interface_addresses; > select cpu_info.* from cpu_info; -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forward Xu updated CALCITE-3329: Description: Implement osquery command for OS adapter, Achieve similar features of FaceBook's osquery. E.g: select * from os_version; select * from system_info; select * from mounts; select * from interface_addresses select * from memory_info; SELECT * FROM interface_addresses; select cpu_info.* from cpu_info was:Implement osquery command for OS adapter > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Implement osquery command for OS adapter, Achieve similar features of > FaceBook's osquery. E.g: > select * from os_version; > select * from system_info; > select * from mounts; > select * from interface_addresses > select * from memory_info; > SELECT * FROM interface_addresses; > select cpu_info.* from cpu_info -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3329: Labels: pull-request-available (was: ) > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Priority: Major > Labels: pull-request-available > > Implement osquery command for OS adapter -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3329) Implement osquery for OS adapter
[ https://issues.apache.org/jira/browse/CALCITE-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forward Xu updated CALCITE-3329: Summary: Implement osquery for OS adapter (was: Implement osquery command for OS adapter) > Implement osquery for OS adapter > > > Key: CALCITE-3329 > URL: https://issues.apache.org/jira/browse/CALCITE-3329 > Project: Calcite > Issue Type: New Feature >Reporter: Forward Xu >Priority: Major > > Implement osquery command for OS adapter -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CALCITE-3329) Implement osquery command for OS adapter
Forward Xu created CALCITE-3329: --- Summary: Implement osquery command for OS adapter Key: CALCITE-3329 URL: https://issues.apache.org/jira/browse/CALCITE-3329 Project: Calcite Issue Type: New Feature Reporter: Forward Xu Implement osquery command for OS adapter -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924748#comment-16924748
]
Julian Feinauer commented on CALCITE-3328:
--
I see. Its probably debatable which approach fits better.
But generally I like to think about donating such things to commons (or else)
as one may want to use it in other projects and its cleaner to include commons.
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924746#comment-16924746
]
Julian Hyde commented on CALCITE-3328:
--
I looked, but couldn't find anything; for example, [Stephen Colebourne looks at
3 libraries|https://blog.joda.org/2016/09/code-generating-beans.html] but all
use code-generation.
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-3328:
Assignee: Julian Hyde
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3328:
-
Description:
In quite a few places we have immutable config classes, and because they are
immutable we have builders. It all gets quite verbose.
I propose to add a utility class, {{ImmutableBeans}}, that is able to generate
an implementation of a given interface. For example,
{code:java}
interface MyBean {
@Property int getAge();
MyBean withAge(int age);
@Property String getName();
MyBean withName(String name);
}
MyBean b = ImmutableBeans.create(MyBean.class);
assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
{code}
We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
{{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}} classes,
and perhaps quite a few fluent classes that we use in tests.
Work in progress:
https://github.com/julianhyde/calcite/tree/3328-immutable-beans
was:
In quite a few places we have immutable config classes, and because they are
immutable we have builders. It all gets quite verbose.
I propose to add a utility class, {{ImmutableBeans}}, that is able to generate
an implementation of a given interface. For example,
{code:java}
interface MyBean {
@Property int getAge();
MyBean withAge(int age);
@Property String getName();
MyBean withName(String name);
}
MyBean b = ImmutableBeans.create(MyBean.class);
assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
{code}
We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
{{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}} classes,
and perhaps quite a few fluent classes that we use in tests.
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924744#comment-16924744
]
Julian Feinauer commented on CALCITE-3328:
--
I agree that this is a very good idea but also wonder why there is no default
for something like that. Wouldnt this be something for apache commons as also
other projects may need that?
And second question: Do we use custom annotations or do we use generic ones
(JEE, ...) for that?
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3328:
-
Description:
In quite a few places we have immutable config classes, and because they are
immutable we have builders. It all gets quite verbose.
I propose to add a utility class, {{ImmutableBeans}}, that is able to generate
an implementation of a given interface. For example,
{code:java}
interface MyBean {
@Property int getAge();
MyBean withAge(int age);
@Property String getName();
MyBean withName(String name);
}
MyBean b = ImmutableBeans.create(MyBean.class);
assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
{code}
We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
{{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}} classes,
and perhaps quite a few fluent classes that we use in tests.
was:
In quite a few places we have immutable config classes, and because they are
immutable we have builders. It all gets quite verbose.
I propose to add a utility class, {{ImmutableBeans}}, that is able to generate
an implementation of a given interface. For example,
{code:java}
interface MyBean {
@Property int getAge();
@Property String getName();
}
MyBean b = ImmutableBeans.create(MyBean.class);
assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
{code}
We could replace SqlParser.ConfigBuilder, Frameworks.ConfigBuilder,
RelBuilder.ConfigBuilder, quite a few of the associated Config classes, and
perhaps quite a few fluent classes that we use in tests.
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3328) Immutable beans, powered by reflection
Julian Hyde created CALCITE-3328:
Summary: Immutable beans, powered by reflection
Key: CALCITE-3328
URL: https://issues.apache.org/jira/browse/CALCITE-3328
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
In quite a few places we have immutable config classes, and because they are
immutable we have builders. It all gets quite verbose.
I propose to add a utility class, {{ImmutableBeans}}, that is able to generate
an implementation of a given interface. For example,
{code:java}
interface MyBean {
@Property int getAge();
@Property String getName();
}
MyBean b = ImmutableBeans.create(MyBean.class);
assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
{code}
We could replace SqlParser.ConfigBuilder, Frameworks.ConfigBuilder,
RelBuilder.ConfigBuilder, quite a few of the associated Config classes, and
perhaps quite a few fluent classes that we use in tests.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
