users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: BNF question: how to parse the example containing KEY, VALUE (and LIKE)

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Mon, 26 Mar 2012 14:20:42 -0700

Hi Michael,

On 3/26/2012 2:14 PM, Michael Bouschen wrote:
> Hi Linda,
>
> more below ...
>> Hi Michael,
>>
>> Thanks for following up on this. More below....
>>
>> On 3/22/2012 3:50 PM, Michael Bouschen wrote:
>>> Hi Linda,
>>>> Hi Michael,
>>>>
>>>> On 3/19/2012 3:26 PM, Michael Bouschen wrote:
>>>>> Hi Linda,
>>>>>> Hi Christian,
>>>>>>
>>>>>> On 3/19/2012 6:54 AM, Christian Romberg wrote:
>>>>>>> Dear group,
>>>>>>>
>>>>>>> While investigating how to parse queries like this (all page/chapter references refer to EDR 2.1, Dec 19th, 2011):
>>>>>>>
>>>>>>> SELECT p
>>>>>>> FROM Person p, in(pc.firstnames) n
>>>>>>> WHERE n = 'Joe'
>>>>>>>
>>>>>>> (firstnames is a List<String>)
>>>>>>>
>>>>>>> I came across the following example provided in the spec, which is related in structure:
>>>>>>>
>>>>>>> section 4.4.4, p. 153:
>>>>>>>
>>>>>>> SELECT i.name <http://i.name>, VALUE(p)
>>>>>>> FROM Item i JOIN i.photos p
>>>>>>> WHERE KEY(p) LIKE ‘%egret’
>>>>>>>
>>>>>>> I looked at the BNF how this is parsed, and did not find any derivation for the FROM clause:
>>>>>>>
>>>>>>> where_clause ::= WHERE conditional_expression
>>>>>>> conditional_expression ::= conditional_term
>>>>>>> conditional_term ::= conditional_factor
>>>>>>> conditional_factor ::= conditional_primary
>>>>>>> conditional_primary ::= simple_cond_expression
>>>>>>> simple_cond_expression ::= like_expression
>>>>>>> like_expression ::= string_expression LIKE pattern_value
>>>>>>>
>>>>>>> So eventually I end up with 'string_expression', from which I can not derive a 'qualified_identification_variable'
>>>>>>>
>>>>>>> string_expression ::=
>>>>>>> state_field_path_expression |
>>>>>>> string_literal |
>>>>>>> input_parameter |
>>>>>>> functions_returning_strings |
>>>>>>> aggregate_expression |
>>>>>>> case_expression |
>>>>>>> function_invocation |
>>>>>>> (subquery)
>>>>>>>
>>>>>>> Did I miss something, or is there actually a rule missing in the grammar for this?
>>>>>>
>>>>>> Yes, you are right. The problem is that composable_qualified_identification_variable
>>>>>> is currently assumed to not designate a state field, which it should.
>>>>>>
>>>>>> Not sure yet what the best fix for this is in the grammar yet.
>>>>> would it work if we add composable_qualified_identification_variable as an additional alternative in string_expression
>>>>> (and datetime_expressio etc.):
>>>>>
>>>>
>>>> I believe so, but I think we have to go further. I.e., I think we need to support this also
>>>> in in_expression, function_arg, case_operand, aggregate_expression, and entity_or_value_expression.
>>>>
>>>> Do you agree?
>>>
>>> yes agreed. The same holds true for orderby_item, correct?
>>>
>>
>> Yes, orderBy_item needs to be covered as well.
>>
>> I am hesitating about adding composable_qualified_identification_variable
>> to state_field_path_expression though, because a key may often not be a
>> state field of the object that is the map value. I'm also concerned
>> about the order-by rules. E.g.,
>>
>> @Entity
>> public class Company {
>> @Id int id;
>> ...
>> @OneToMany // map key is division name
>> Map<String, VicePresident> organization;
>>
>>
>> The following query shouldn't work, because the key is
>> not part of the result.
> I agree, the above query should not work. But how about returning the key that is used in the order by:
>
> SELECT key(vp)
> FROM Company c JOIN c.organization vp
> WHERE vp.reports > 100
> ORDER BY key(vp)
>

Yes. I agree that this should be legal.

> I think this query should be legal. This means the orderby_item needs to be covered the same as all the other places we
> discussed where composable_qualified_identification_variable needs to be added. But maybe we should extend the rules for
> the orderby_item as specified in chapter 4.9 on pages 183/184. We could add composable_qualified_identification_variable
> to the second rule that covers state_field_path_expression already.
>

Yes, only I would cover this as a separate rule (to make it very clear).

>> SELECT vp
>> FROM Company c JOIN c.organization vp
>> WHERE vp.reports > 100
>> ORDER BY key(vp)
>>
>>
>> So, I was thinking of just either adding composable_qualified_identification_variable to
>> the needed places (ugly) or defining another non-terminal, e.g.,
>> generalized_state_expression::= state_field_path_expression | composable_qualified_identification_variable.
>>
>> What do you think?
>
> I like the idea of having another non-terminal because a composable_qualified_identification_variable like key(vp) is
> not really a state_field_path_expression.
> That would mean the new non-terminal generalized_state_expression is used in all the places we discussed before, correct?
>

Yes.

Thanks again! It looks like we're on the same page here.

regards,

-Linda



> Regards Michael
>
>>
>> regards,
>>
>> -Linda
>>
>>
>>
>>> So maybe we extend state_field_path_expression and add composable_qualified_identification_variable as an alternative:
>>>
>>> state_field_path_expression ::=
>>> general_subpath.state_field |
>>> composable_qualified_identification_variable
>>>
>>> Regards Michael
>>>
>>>>
>>>> regards,
>>>>
>>>> -Linda
>>>>
>>>>> string_expression ::=
>>>>> state_field_path_expression |
>>>>> composable_qualified_identification_variable |
>>>>> string_literal |
>>>>> ...
>>>>>
>>>>> Regards Michael
>>>>>
>>>>>>
>>>>>> Thanks for pointing this out.
>>>>>>
>>>>>> -Linda
>>>>>>
>>>>>> \
>>>>>>>
>>>>>>> Thank you!
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christian Romberg
>>>>>>> Chief Engineer| Versant GmbH
>>>>>>> (T) +49 40 60990-0 <tel:%2B49%2040%2060990-0>
>>>>>>> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
>>>>>>> (E) cromberg_at_versant.com <mailto:cromberg_at_versant.com>
>>>>>>> www.versant.com
>>>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwww.versant.com%2F&sa=D&sntz=1&usg=AFrqEzeeEBc_gN_8mxtt8xDB0tjXDXQVlw>|
>>>>>>> www.db4o.com
>>>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwww.db4o.com%2F&sa=D&sntz=1&usg=AFrqEzdo3Q40RwKQPBtnPIuBYQd1diFxJQ>
>>>>>>>
>>>>>>> --
>>>>>>> Versant
>>>>>>> GmbH is incorporated in Germany. Company registration number: HRB
>>>>>>> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
>>>>>>> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>>>>>>>
>>>>>>> CONFIDENTIALITY
>>>>>>> NOTICE: This e-mail message, including any attachments, is for the sole
>>>>>>> use of the intended recipient(s) and may contain confidential or
>>>>>>> proprietary information. Any unauthorized review, use, disclosure or
>>>>>>> distribution is prohibited. If you are not the intended recipient,
>>>>>>> immediately contact the sender by reply e-mail and destroy all copies of
>>>>>>> the original message.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Michael Bouschen*
>>>>> *Prokurist*
>>>>>
>>>>> akquinet tech_at_spree GmbH
>>>>> Bülowstr. 66, D-10783 Berlin
>>>>>
>>>>> Fon: +49 30 235 520-33
>>>>> Fax: +49 30 217 520-12
>>>>> Email: michael.bouschen_at_akquinet.de
>>>>> Web: www.akquinet.de <http://www.akquinet.de>
>>>>>
>>>>> akquinet tech_at_spree GmbH, Berlin
>>>>> Geschäftsführung: Martin Weber, Dr. Torsten Fink
>>>>> Amtsgericht Berlin-Charlottenburg HRB 86780 B
>>>>> USt.-Id. Nr.: DE 225 964 680
>>>
>>>
>>> --
>>> *Michael Bouschen*
>>> *Prokurist*
>>>
>>> akquinet tech_at_spree GmbH
>>> Bülowstr. 66, D-10783 Berlin
>>>
>>> Fon: +49 30 235 520-33
>>> Fax: +49 30 217 520-12
>>> Email: michael.bouschen_at_akquinet.de
>>> Web: www.akquinet.de <http://www.akquinet.de>
>>>
>>> akquinet tech_at_spree GmbH, Berlin
>>> Geschäftsführung: Martin Weber, Dr. Torsten Fink
>>> Amtsgericht Berlin-Charlottenburg HRB 86780 B
>>> USt.-Id. Nr.: DE 225 964 680
>
>
> --
> *Michael Bouschen*
> *Prokurist*
>
> akquinet tech_at_spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon: +49 30 235 520-33
> Fax: +49 30 217 520-12
> Email: michael.bouschen_at_akquinet.de
> Web: www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech_at_spree GmbH, Berlin
> Geschäftsführung: Martin Weber, Dr. Torsten Fink
> Amtsgericht Berlin-Charlottenburg HRB 86780 B
> USt.-Id. Nr.: DE 225 964 680