[
https://issues.apache.org/jira/browse/CALCITE-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567432#comment-16567432
]
Vladimir Sitnikov edited comment on CALCITE-2439 at 8/2/18 8:10 PM:
--------------------------------------------------------------------
{quote}I think it adds too much complexity if there is more than one table
function.{quote}
Well, I'm thinking of non-table, scalar function to weight options.
That is table function would provide "possible options", and scalar function
(or several of them) could weight.
For instance:
{code:sql}
{quote}It seems to me that we would need to generate a regexp from "cd". That
regexp would determine which of the completions are acceptable.
{quote}
Well, I thought of something between those lines.
Several regexps might be required to sort the completions properly (e.g.
prefix match is more relevant than substring match).
{quote}they should specify the algorithm that they want to use to generate the
regexp.
{quote}
Do you know the proper way to expose that via API?
Here's current API:
{code:sql}
select t.* from table(getHints('select ...', 42)) as t(id, names, type)}{code}
Note: the replaced word is returned as a first row of the result with
{{type==MATCH}}.
Theoretically we could use something like
{code:sql}
select * from (
select t.id, t.names, t.type
, getMatchRelevance(t.names, t.match, 'prefix-case-insensitive')
prefix_relevance
, getMatchRelevance(t.names, t.match, 'substring-case-insensitive')
substring_relevance
, getMatchRelevance(t.names, t.match, 'subsequence-case-insensitive')
subsequence_relevance
...
from table(getHintsNoFilter('select ...', 42)) as t(id, names, type, match)
)
where prefix_relevance>0 or substring_relevance>0 or subsequence_relevance>0
order by prefix_relevance, substring_relevance, subsequence_relevance,
t.names{code}
was (Author: vladimirsitnikov):
{quote}I think it adds too much complexity if there is more than one table
function.{quote}
Well, I'm thinking of non-table, scalar function to weight options.
That is table function would provide "possible options", and scalar function
(or several of them) could weight.
> Smart complete for SqlAdvisor
> -----------------------------
>
> Key: CALCITE-2439
> URL: https://issues.apache.org/jira/browse/CALCITE-2439
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.17.0
> Reporter: Vladimir Sitnikov
> Assignee: Julian Hyde
> Priority: Major
>
> Current implementation of SqlAdvisor provides no way to perform smart
> complete.
> For example,
> 1) A valid completion for {{select cd^ from clients}} might be {{select
> client_id from clients}}.
> That is completion is valid if all input characters are represented in final
> word in a proper sequence.
> 2) Completion might be case-insensitive if all input characters have the same
> upper/lower case.
> 3) "Contains" might be valid completion option as well. That is {{select id^
> from ...}} might be completed to \{{select client_id from...} as well.
> Of course, exact match should be sorted the first, then partial matches and
> so on.
> It is not clear if smart complete logic belongs to {{SqlAdvisor}} or not.
> Current client-facing API provides no way to skip default "case-sensitive
> prefix filtering", so there's no way to implement smart complete at the
> client side only.
> It is not clear where this logic belongs:
> a) Ultimate solution would be "skip filtering the identifiers at SqlAdvisor
> side". Then client can filter and sort the way it wants. The downside of the
> approach is it would force client to pipe large amount of items across JDBC
> bridge
> b) It might be helpful if Calcite had pre-defined implementations that would
> filter and sort the results. The good part is it simplifies client
> development, however various clients might have various filters applied.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
