[
https://issues.apache.org/jira/browse/CALCITE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328114#comment-14328114
]
Vladimir Sitnikov commented on CALCITE-601:
-------------------------------------------
{quote}but radically different at planning time{quote}
Julian, BINDABLE convention has _lots_ of open questions. Let's discuss it in
CALCITE-584?
{quote}Code that is constructing a result set knows {quote}
Here's my point: if you want move ENUMERABLE out of core, then you need to have
strong API interfaces _in_ core.
I do not accept the following as a strong communication API. Do you?
{code:java}
public interface Bindable<T> {
/**
* Executes this statement and returns an enumerable which will yield rows.
* The {@code environment} parameter provides the values in the root of the
* environment (usually schemas).
*
* @param dataContext Environment that provides tables
* @return Enumerable over rows
*/
Enumerable<T> bind(DataContext dataContext);
}
{code}
How on Earth would you guess what the return type is?
Well, please suggest your way if you have something in mind. I might be missing
something.
I can accept short term coupling of CursorFactory with exact conventions,
however it (calling ENUMERABLE SPI right in CalcitePrepare) does not make much
sense if we want moving executors (i.e. ENUMERABLE) out of core.
PS:
Why on Earth the method is called {{bind}}?
I think {{execute}} would be much cleaner method name.
I'm not sure what's better name for {{Bindable.class}} itself, but something
similar to {{PreparedStatement}} would be much cleaner.
> 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)
