Hi Tom,
thanks, I'll check it in tomorrow.
Regards Michael
> The fix looks good. Go ahead and check it in if you want.
>
> -Tom
>
> Michael Bouschen wrote:
>
>> Resend, because of mail issues.
>>
>> Hi Tom,
>>
>> I looked into EJBQL queries using the NOT operator in the WHERE clause
>> and I found two cases where the generated SQL is not correct:
>> (1) ... WHERE NOT (NOT (c.name = 'Michael Bouschen'))
>> (2) ... WHERE NOT c.name <> 'Michael Bouschen'
>> The SQL WHERE clause for both queries misses a NOT operator:
>> ... WHERE NOT ((NAME = 'Michael Bouschen'))
>>
>> I think (I hope) I fixed the problem, you find a fix attached below.
>> Here are some details about the fix. Problem (1) is caused by method
>> handleRightRoundBracket calling finishedConstructingNode instead of
>> finishedExpression. Only the latter takes care of any pending not
>> operations to be added before the helper instance is closed. The reason
>> for (2) is that the ParseTreeNodeConstructor does not support having two
>> NOT operations in the same context, method handleNot overwrites any
>> notNode registered before. An expression "x<>y" is mapped to NOT x=y, so
>> query (2) is mapped to a query with two NOT operators. I fixed the code
>> in ParseTreeNodeConstructor.handleNot.
>>
>> Please have a look. Thanks!
>>
>> Regards Michael
>>
>>