[
https://issues.apache.org/jira/browse/ASTERIXDB-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cameron Samak updated ASTERIXDB-2915:
-------------------------------------
Priority: Major (was: Minor)
> SQL++ UDF parsing fails in some cases (diverges from normal parser)
> -------------------------------------------------------------------
>
> Key: ASTERIXDB-2915
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-2915
> Project: Apache AsterixDB
> Issue Type: Bug
> Components: SQL - Translator SQL++
> Reporter: Cameron Samak
> Assignee: Cameron Samak
> Priority: Major
>
> {{SqlppParserFactory.createParser(Reader)}} creates invalid parsers that fail
> tests, since {{setInput}} isn't called in {{SQLPPParser}} so the
> {{ScopeChecker}} isn't properly initialized.
> This means that error messages won't work correctly, and some SQLPP is not
> parseable. In other words, only one of the two construction methods in
> {{IParserFactory}} actually works correctly.
> However it is only used by UDF code, so we don't catch this issue normally.
> A sample query that fails is
> {{optimizerts/queries/group-by/gby-case-01.4.sqlpp.}}
>
> Reproduce more failure cases by changing
> SqlppParserFactory.createParser(String) to
> {code:java}
> public IParser createParser(String query) {
> return createParser(new StringReader(query));
> } {code}
> which will generate lots of failures with the existing test suite.
>
>
> For a fix, we should
> # not rely on a {{setInput}} like this (initialization should be done in the
> constructor, or we might forget to do it). This probably requires
> restructuring the parser so it does not extend from {{ScopeChecker}}.
> # probably remove the reader way of constructing parsers (possibly out of
> scope here though).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
