Re: [jira] Updated: (CAY-1371) EJBQL query doesn't preserve grouping by brackets

[Andrus Adamchik <an...@objectstyle.org>]

>> 4.6.6 Operators and Operator Precedence
>> The operators are listed below in order of *decreasing precedence*.
>> ...
>> • Logical operators:
>> NOT
>> AND
>> OR

Ok. It is not clear from the spec whether "decreasing precedence" is  
between each bullet in the list or whether this is also within each  
bulleted section. But from the BNF (and our parser), I'd take your  
interpretation (e.g. "and" expressions are always grouped before "or"  
is applied to groups). So then everything makes sense.

Beats me why the authors could not write it explicitly like this, but  
anyways...  http://java.sun.com/docs/books/tutorial/java/nutsandbolts/operators.html

>>
>> And what about jjtGetParent()?

This is the correct method. Generated by JavaCC, so it looks ugly like  
that, still that's the one.

So +1 for the patch.

Andrus

On Jan 24, 2010, at 1:11 PM, Andrey Razumovsky wrote:

> On the last lines, I meant
> a or b and c -- will translate to --> a or b and c, while
> (a or b) and c -- will translate to --> (a or b) and c.
>
> So brackets only when needed
>
>
> 2010/1/24 Andrey Razumovsky <ra...@gmail.com>
>
>> 4.6.6 Operators and Operator Precedence
>> The operators are listed below in order of *decreasing precedence*.
>> ...
>> • Logical operators:
>> NOT
>> AND
>> OR
>>
>> So e.g.
>> a or b and c
>> equals to
>> a or (b and c)
>>
>> Actually it's the same in any language, e.g. in Java.
>> currently our translator has no notion of brackets around  
>> statements at
>> all. We could insert them everywhere (like in Andreas's patch) -  
>> but it's
>> cleaner insert them only when needed. So
>> a or b and c -- will translate to --> a or (b and c), while
>> a and b and c -- will translate to --> a and b and c.
>>
>> And what about jjtGetParent()?
>>
>> 2010/1/24 Andrus Adamchik <an...@objectstyle.org>
>>
>> As I said, I don't understand 'needBracket' logic.
>>>
>>> Per Andreas's example, the parser already does the correct  
>>> grouping based
>>> on user specified parentheses. So all we need to do is to eagerly  
>>> place "("
>>> and ")" around each conditional node. So Andreas's patch was doing  
>>> the right
>>> thing (of course it also needed handling of AND and NOT).
>>>
>>> And that's what we are already doing for SelectQuery qualifiers.  
>>> Although
>>> IIRC we have a "flattenning" algorithm to skip parentheses in  
>>> uniformly
>>> joined 3+ term conditions.. Was that the intention of  
>>> 'needBracket'?.
>>>
>>> Andrus
>>>
>>>
>>> On Jan 24, 2010, at 12:39 PM, Andrus Adamchik wrote:
>>>
>>> Where does the notion of priority come from? Logically (and from the
>>>> spec) OR/AND/NOT all have the same priority.
>>>>
>>>> Andrus
>>>>
>>>> On Jan 24, 2010, at 12:02 PM, Andrey Razumovsky (JIRA) wrote:
>>>>
>>>> Andrey Razumovsky updated CAY-1371:
>>>>> -----------------------------------
>>>>>
>>>>> Attachment: 1371.txt
>>>>>
>>>>> Patch that fixes the issue. Not committing it just yet, because  
>>>>> I'm not
>>>>> sure about patterns of expression processing. Is it correct to  
>>>>> call
>>>>> jjtGetParent() ? If so, why isn't there a method with more  
>>>>> suitable name?
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Andrey
>>
>
>
>
> -- 
> Andrey