[
https://issues.apache.org/jira/browse/CALCITE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327824#comment-14327824
]
Vladimir Sitnikov edited comment on CALCITE-601 at 2/19/15 8:59 PM:
--------------------------------------------------------------------
In fact it does not.
You might probably want to hack
{{org.apache.calcite.adapter.enumerable.EnumerableRelImplementor#implementRoot}},
however I do not like that since it would diverge APIs. Bindable vs enumerable
battle is not yet over, thus I do not want to diverge things unless it makes
sense.
See: if we consider "ENUMERABLE convention" as a pluggable implementation, then
base interface should be capable to support features.
In other words, things like "if (instanceof ENUMERABLE) \{ grab shape from
it\}" do not suit "core" component with "ENUMERABLE" being a plug-in.
Here's one more relevant use-case: "accept of {{cursor}} parameter". It is not
clear what calling convention should be.
It would be nice to make it clear what will be passed in the parameter.
{{Enumerable<Object\[\]>}} or {{Enumerable<Class>}} or {{ResultSet}} or
whatever.
It would be nice to have "converter" out of the box.
If all plays well, we could probably make JdbcToEnumerable to bypass code
generation by simple composition of "ResultSet shape vs Meta.CursorFactory"
was (Author: vladimirsitnikov):
In fact it does not.
You might probably want to hack
{{org.apache.calcite.adapter.enumerable.EnumerableRelImplementor#implementRoot}},
however I do not like that since it would diverge APIs. Bindable vs enumerable
battle is not yet over, thus I do not want to diverge things unless it makes
sense.
See: if we consider "Enumerable convention" as a pluggable implementation, then
base interface should be capable to support features.
In other words, things like "if (instanceof enumerable) \{ grab shape from
it\}" do not suit "core" component with "enumerable" being a plug-in.
Here's one more relevant use-case: "accept of {{cursor}} parameter". It is not
clear what calling convention should be.
It would be nice to make it clear what will be passed in the parameter.
{{Enumerable<Object\[\]>}} or {{Enumerable<Class>}} or {{ResultSet}} or
whatever.
It would be nice to have "converter" out of the box.
If all plays well, we could probably make JdbcToEnumerable to by-pass code
generation by simple composition of "ResultSet shape vs Meta.CursorFactory"
> Meta.CursorFactory#deduce should not try to check column count
> --------------------------------------------------------------
>
> Key: CALCITE-601
> URL: https://issues.apache.org/jira/browse/CALCITE-601
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.0.0-incubating
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
>
> Current implementation of {{Meta.CursorFactory#deduce}} thinks that
> Enumerable with single column cannot be {{Object\[\]}} wrapped.
> This sounds like an extreme high coupling.
> I think it makes sense if "Bindable" would provide its {{JavaRowFormat}}
> along with "ElementType".
> I think it makes sense to reject non-typed, non-rowformatproviding Bindables
> out of Enumerable/Bindable conventions.
> {code:java}
> public static CursorFactory deduce(List<ColumnMetaData> columns,
> Class resultClazz) {
> if (columns.size() == 1) {
> return OBJECT; // <-- !! Look here. deduce just assumes
> single-column results are always naked
> } else if (resultClazz != null && !resultClazz.isArray()) {
> return record(resultClazz);
> } else {
> return ARRAY;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
