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)
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.
> 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?
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