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