Bug #2448
DynamicQueryHelper.parse accepts predicate with garbage after terminating dot
0%
History
#1 Updated by Vadim Nebogatov over 9 years ago
Test case in testcases/uast/query/query_prepare_dot_colon.p
.
Vadim Nebogatov wrote:
All cases correspond to 4GL behavior excepting case
Query string | 4GL | P2J |
---|---|---|
l = h:query-prepare("for each person where person.emp-num = 2 use-index hire-date.qwerty"). | ** Unable to understand after -- "use-index hire-date". (247) PREPARE syntax is: {FOR I PRESELECT} EACH OF.. WHERE ... etc". (7324) | Success |
It means that 4GL resolves tables and columns in QUERY-PREPARE stage, but P2J seems not.
Eric Faulhaber wrote:
I'm worried that this case might break our plan to do this "on the cheap" (i.e., without changing the Progress parser). In order to identify that the trailing
.qwerty
is garbage and should cause errors to be raised, we need to consume all of the predicate up to that point in a context-aware manner. I think it would be too complicated to do this in some ad-hoc analysis code inDynamicQueryHelper
, as we would have to recreate the complex query parsing which allows us to recognize the valid elements of the predicate, which the Progress parser already does.
The question is, do we defer this change to the Progress parser and omit support for this edge case for now, in order to support the rest of the cases at this time?
Greg: I would have expected the parser to stumble on the.qwerty
trash at the end of the predicate in this case, but it doesn't. Is this a bug?
Greg Shah wrote:
Greg: I would have expected the parser to stumble on the .qwerty trash at the end of the predicate in this case, but it doesn't. Is this a bug?
Remember that our parser assumes that the code provided is VALID 4GL. You are passing in total crap. All bets are off at that point. In particular, I suspect that we parse out the
hire-date.qwerty
as theINDEX
in the@use_index_clause@ becauseany_non_reserved_symbol
is allowed to have.
qualifiers there. We don't check that that particular value is a valid index, we just parse it and move on.Actually, that is what the 4GL does too, but it does additional checking about the
INDEX
which it finds to be non-sense and then it complains. I would have thought that your database conversion processing would similarly fail at some point downstream from the parser when you can't figure out what that index is.I'm worried that this case might break our plan to do this "on the cheap" (i.e., without changing the Progress parser).
This isn't about "cheap". I am trying to avoid making the parser more complicated in order to handle special cases that are not normally processed in "real" 4GL code. The parser is complicated enough without more special cases.
It is also important that you feed in valid 4GL code to the parser.