[jira] [Comment Edited] (CALCITE-2434) SqlAdvisor.getCompletionHints does not work for nested identifiers sub-match

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

    [ https://issues.apache.org/jira/browse/CALCITE-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583046#comment-16583046 ] 

Vladimir Sitnikov edited comment on CALCITE-2434 at 8/16/18 9:08 PM:
---------------------------------------------------------------------

[~julianhyde],  current {{org.apache.calcite.sql.validate.SqlValidatorWithHints}} produces hints as follows:
{code:java}List<SqlMoniker> lookupHints(SqlNode topNode, SqlParserPos pos);{code}

In other words, if {{select * from sales.e^}} autocompletes to {{catalog.sales.emps}}, then SqlMoniker would be {{CATALOG.SALES.EMPS}}, and it does store information that {{e}} should be replaced with {{emps}}, and not with {{sales.emps}} or even {{catalog.sales.emps}}.

I'm going to add relevant methods to {{SqlMoniker}} to designate either "number of already present in the query parts of name"
For instance, for {{sales.e^}} and {{catalog.sales.emps}} it would return 2 meaning the first two names are already present in the query.

There's alternative option to resolve the case like 
1. Identify "location of identifier before the dot". It seems to be non-trivial as  there might be whitespace/comments between sales/**/./**/emps
2. Issue {{org.apache.calcite.sql.validate.SqlValidatorWithHints#lookupQualifiedName}} to get full name of identifier before the dot
3. Assume autocomplete builds upon the existing name.

The problem with that approach is: it does not seem trivial to identify the location "before the dot", and it looks like {{SqlValidatorWithHints#lookupQualifiedName}} always returns null (the thing is the methods works only after full validation of the query, and it hardly happens for partially-complete SQL).


was (Author: vladimirsitnikov):
[~julianhyde],  current {{org.apache.calcite.sql.validate.SqlValidatorWithHints}} produces hints as follows:
{code:java}List<SqlMoniker> lookupHints(SqlNode topNode, SqlParserPos pos);{code}

In other words, if {{select * from sales.e^}} autocompletes to {{catalog.sales.emps}}, then SqlMoniker would be {{CATALOG.SALES.EMPS}}, and it does store information that {{e}} should be replaced with {{emps}}, and not with {{sales.emps}} or even {{catalog.sales.emps}}.

I'm going to add relevant methods to {{SqlMoniker}} to designate either "number of already present in the query parts of name"
For instance, for {{sales.e^}} and {{catalog.sales.emps}} it would return 2 meaning the first two names are already present in the query.

> SqlAdvisor.getCompletionHints does not work for nested identifiers sub-match
> ----------------------------------------------------------------------------
>
>                 Key: CALCITE-2434
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2434
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.17.0
>            Reporter: Vladimir Sitnikov
>            Assignee: Vladimir Sitnikov
>            Priority: Major
>
> Test (SqlAdvisorTest):
> {code:java}  @Test public void testNestSchema() throws Exception {
>     String sql;
>     sql = "select * from sales.n^";
>     assertComplete(
>         sql,
>     ...);
> }
> {code}
> Expected output: "SALES.NEST" schema and tables inside and so on
> Actual output: empty.
> The thing is it properly uses {{n}} for prefix search, however it uses {{hint.toString()}} and it fails for multi-name identifiers:
> {code:java}        // Regular identifier. Case-insensitive match.
>         for (SqlMoniker hint : completionHints) {
>           String cname = hint.toString();
>           if ((cname.length() >= word.length())
>               && cname.substring(0, word.length()).equalsIgnoreCase(word)) {
>             result.add(hint);
>           }
>         }
> {code}
> Hints are like "CATALOG.SALES.NEST", and they fail {{cname.substring(0, word.length()).equalsIgnoreCase(word)}} check



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)