asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cameron Samak (Jira)" <j...@apache.org>
Subject [jira] [Updated] (ASTERIXDB-2915) SQL++ UDF parsing fails in some cases (diverges from normal parser)
Date Mon, 14 Jun 2021 16:31:00 GMT

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

Mime
View raw message