FAQ
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 <andrus@objectstyle.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, andrey@apache.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

Search Discussions

  • Andrus Adamchik at Jan 21, 2010 at 8:55 pm

    On Jan 21, 2010, at 10:38 PM, Andrey Razumovsky wrote:

    So, following specification, this cannot be performed anyhow?
    No. But the idea I guess is that pattern is not another column value.
    It is always a literal.
    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?
    I think it doesn't buy us much. LIKE is a rather special case IMO, and
    this is reflected in the spec.
    Another weird thing is that pattern_value() unlike other expressions
    is not
    described in BNF on pages 109-112..
    True. It is described in the text only. The EJBQL BNF is rather
    sketchy in some parts.

    Andrus
  • Andrey Razumovsky at Jan 21, 2010 at 9:19 pm
    I've always thought of EJBQL as of sort of OOP-analogue of SQL. So while
    those thinks look logical and work in SQL, why shouldn't they in EJBQL..
    So I'm not fully convinced, but if you wish (?), I'll revert that change

    2010/1/21 Andrus Adamchik <andrus@objectstyle.org>
    On Jan 21, 2010, at 10:38 PM, Andrey Razumovsky wrote:

    So, following specification, this cannot be performed anyhow?
    No. But the idea I guess is that pattern is not another column value. It is
    always a literal.


    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?
    I think it doesn't buy us much. LIKE is a rather special case IMO, and this
    is reflected in the spec.


    Another weird thing is that pattern_value() unlike other expressions is
    not
    described in BNF on pages 109-112..
    True. It is described in the text only. The EJBQL BNF is rather sketchy in
    some parts.

    Andrus

    --
    Andrey
  • Andrus Adamchik at Jan 22, 2010 at 8:08 am

    On Jan 21, 2010, at 11:19 PM, Andrey Razumovsky wrote:

    I've always thought of EJBQL as of sort of OOP-analogue of SQL. So
    while
    those thinks look logical and work in SQL, why shouldn't they in
    EJBQL..
    So I'm not fully convinced, but if you wish (?), I'll revert that
    change
    Thanks for doing that. The way I see the EJBQL evolution in Cayenne is
    that in 3.0 it is String-only, JPA-compatible. In 3.1+ it becomes an
    API or String-based (CQL extends EJBQL), JPA compatible, but with
    Cayenne extensions.

    Andrus
  • Andreas Hartmann at Jan 21, 2010 at 9:35 pm

    Am 21.01.10 21:54, schrieb Andrus Adamchik:
    On Jan 21, 2010, at 10:38 PM, Andrey Razumovsky wrote:

    So, following specification, this cannot be performed anyhow?
    No. But the idea I guess is that pattern is not another column value. It
    is always a literal.
    Yes, the tutorial emphasizes this: "The pattern value is a string
    literal that may contain wildcard characters."

    http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBQL5.html

    I find this restriction rather strange, but maybe the authors couldn't
    think of a reasonable real-world scenario which requires a dynamically
    generated pattern.

    -- Andreas

    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?
    I think it doesn't buy us much. LIKE is a rather special case IMO, and
    this is reflected in the spec.
    Another weird thing is that pattern_value() unlike other expressions
    is not
    described in BNF on pages 109-112..
    True. It is described in the text only. The EJBQL BNF is rather sketchy
    in some parts.

    Andrus

    --
    Andreas Hartmann, CTO
    BeCompany GmbH
    http://www.becompany.ch
    Tel.: +41 (0) 43 818 57 01
  • Andreas Hartmann at Jan 21, 2010 at 9:40 pm
    Am 21.01.10 21:54, schrieb Andrus Adamchik:

    […]
    Another weird thing is that pattern_value() unlike other expressions
    is not
    described in BNF on pages 109-112..
    True. It is described in the text only. The EJBQL BNF is rather sketchy
    in some parts.
    They are refering to the SQL spec for a thorough definition of
    pattern_value in the footnote 27 on page 93. It really is only a string
    literal with a special syntax.

    -- Andreas



    --
    Andreas Hartmann, CTO
    BeCompany GmbH
    http://www.becompany.ch
    Tel.: +41 (0) 43 818 57 01

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJan 21, '10 at 8:39p
activeJan 22, '10 at 8:08a
posts6
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2021 Grokbase