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, [email protected] 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
