[
https://issues.apache.org/jira/browse/CALCITE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245873#comment-14245873
]
Vladimir Sitnikov commented on CALCITE-529:
-------------------------------------------
There are two problems here:
1) Lifecycle: the "stashed" object is not connected with the query/statement,
so it is harder to cleanup the resources
2) Boilerplate code: you need to define UDF, make sure it is concurrent-proof
3) Lack of UDF capabilities: you cannot tell Calcite: "this UDF would always
return NOT NULL result". Thus it would perform null checks
4) Performance: you add additional indirection, thus it will hurt
5) When you are in the same JVM, serializability does not matter much. It is
nice to have string representation just in case you print details in explain
plan, however if you just execute a query, then serializability does not matter.
Here's sketch for {{MongoToEnumerableConverter}}.
Compare it with current "black magic of Expressions".
Note how just rule is sufficient and
{{EnumerableRel}}/{{EnumerableRelImplementor}} is not touched at all.
{{EnumerableTableFunctionScan}} requires some improvements (e.g. ability to
define the "physType" of the input/output enumerables), however it is a generic
improvement not tied to Mongo.
{code:java}
@Override public RelNode convert(RelNode rel) {
RelTraitSet newTraitSet = rel.getTraitSet().replace(getOutConvention());
RexBuilder rexBuilder = rel.getCluster().getRexBuilder();
final MongoRel.Implementor mongoImplementor = new MongoRel.Implementor();
mongoImplementor.visitChild(0, rel);
return new EnumerableTableFunctionScan(
rel.getCluster(),
newTraitSet,
ImmutableList.of(),
Object[].class,
rel.getRowType(),
rexBuilder.makeCall(MONGO_AGGREGATE,
rexBuilder.makeLiteral(mongoImplementor.list),
rexBuilder.makeLiteral(rel.getRowType()))
);
}
{code}
{quote}Same kind of restrictions I am talking about.{quote}
I understand why serializable is important when sending data to the remote
server, however I consider main use case for the feature to be in AtoB
converter-like code.
I do not expect client to observe these {{Object}} literals yet.
> Allow to pass java object via rexBuilder.makeLiteral()
> ------------------------------------------------------
>
> Key: CALCITE-529
> URL: https://issues.apache.org/jira/browse/CALCITE-529
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.0.0-incubating
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Labels: newbie
>
> Motivation: Rex is simpler that linq4j.
> For instance,
> 1) Sometimes it is easier to create a {{ProjectRel}} rather than lower the
> expression to low-level linq4j
> 2) XXXToEnumerableRule are easier to accomplish via TableFunctionScan. This
> allows to express the call via Rex and skip linq4j completely.
> For example:
> https://github.com/vlsi/mat-calcite-plugin/blob/master/MatCalcitePlugin/src/com/github/vlsi/mat/optiq/rules/InstanceAccessByClassIdRule.java#L43
> The problem is to pass non-literal java object to enumerable/interpreter
> conventions.
> For enumerable the implementation can use stash. For interpreter it can use
> the value as is, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
