Project

General

Profile

Bug #2448

DynamicQueryHelper.parse accepts predicate with garbage after terminating dot

Added by Vadim Nebogatov over 9 years ago. Updated over 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
11/21/2014
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

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 in DynamicQueryHelper, 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 the INDEX in the@use_index_clause@ because any_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.

Also available in: Atom PDF