[
https://issues.apache.org/jira/browse/CALCITE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326639#comment-14326639
]
Julian Hyde commented on CALCITE-601:
-------------------------------------
It sounds like you're right, and if so, I will hit this as I work through the
issues as I try to set ENABLE_BINDABLE = true.
Note that I have extended interface Bindable: sub-interface ArrayBindable
guarantees to return Object[]s (and its getElementType() method always returns
Object[].class). A BindableRel (i.e. a RelNode of BINDABLE convention)
implements ArrayBindable, and therefore commits to returning Objects[] however
many columns it has.
The interface Bindable is of course used in other places than BINDABLE
convention, but this at least simplifies BINDABLE convention.
> 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)
