[jira] [Comment Edited] (CALCITE-601) Meta.CursorFactory#deduce should not try to check column count

["Vladimir Sitnikov (JIRA)" <ji...@apache.org>]

    [ 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)