Hi Linda and Michael,
We do also need to cover the special short-cut case, that
"VALUE(identification_variable)" is equivalent to just
"identification_variable"
Cheers,
Christian
On Mon, Mar 26, 2012 at 11:20 PM, Linda DeMichiel <
linda.demichiel_at_oracle.com> wrote:
> 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<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=**AFrqEzdo3Q40RwKQPBtnPIuBYQd1di**FxJQ<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
>>
>
--
Christian Romberg
Chief Engineer | Versant GmbH
(T) +49 40 60990-0
(F) +49 40 60990-113
(E) 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.