When changing that, I had in mind not only Andreas's problem, which really
can be easily workarounded. I can think of LIC expression where right part
is also column:
upper(a.address) LIKE upper(b.streetNamePattern).
So, following specification, this cannot be performed anyhow?
I agree subselects in LIKE is not good, then maybe let's change that to
input_parameter() | string_literal() | functions_returning_strings() ?
Specification does not say what to do if right part is not input parameter
or string literal. So is it really bad if we do more than specification
says?
Another weird thing is that pattern_value() unlike other expressions is not
described in BNF on pages 109-112..
2010/1/21 Andrus Adamchik <andru..bjectstyle.org>
> So more specifically, I think if we want to provide likeIgnoreCase
> functionality in CQL (extends EJBQL), we'd rather add a new operator.
>
> Andrus
>
>
> On Jan 21, 2010, at 5:57 PM, Andrus Adamchik wrote:
>
>
>> On Jan 21, 2010, at 11:58 AM, andre..pache.org wrote:
>>
>> Modified:
>>> cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/jjtree/org/apache/cayenne/ejbql/EJBQLParser.jjt
>>> URL:
>>> http://svn.apache.org/viewvc/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/jjtree/org/apache/cayenne/ejbql/EJBQLParser.jjt?rev=901627&r1=901626&r2=901627&view=diff
>>>
>>> ==============================================================================
>>> ---
>>> cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/jjtree/org/apache/cayenne/ejbql/EJBQLParser.jjt
>>> (original)
>>> +++
>>> cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/jjtree/org/apache/cayenne/ejbql/EJBQLParser.jjt
>>> Thu Jan 21 09:58:38 2010
>>>.. -1208,7 +1208,7 @@
>>>
>>> void pattern_value() #PatternValue : { }
>>> {
>>> - input_parameter() | string_literal()
>>> + string_expression()
>>> [(<ESCAPE> escape_character())]
>>> }
>>>
>>
>>
>> -1.
>>
>> This significantly expands the definition of "pattern value" beyond EJBQL
>> spec. The spec on page 93 says:
>>
>> "The pattern_value is a string literal or a string-valued input
>> parameter".
>>
>> I don't see a pressing need for us to deviate from the spec here. A simple
>> workaround that Andreas seems to have been using already is to uppercase the
>> pattern Java String. So it was correct before, and now it allows things like
>> subqueries to be a "pattern_value". SO IMO CAY-1369 was not a bug.
>>
>> Andrus
>>
>>
>>
>>
>
-- Andrey
This archive was generated by hypermail 2.0.0 : Thu Jan 21 2010 - 15:39:40 EST