Skip to main content

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

  • From: Christian Romberg <cromberg@...>
  • To: Linda DeMichiel <linda.demichiel@...>
  • Cc: jsr338-experts@..., Michael Bouschen <michael.bouschen@...>
  • Subject: [jsr338-experts] Re: BNF question: how to parse the example containing KEY, VALUE (and LIKE)
  • Date: Thu, 14 Jun 2012 14:23:46 +0200

Hi Linda,

Any update on the issue below?

Thank you!

Christian

On Wed, Mar 28, 2012 at 9:30 AM, Christian Romberg <cromberg@...> wrote:
Hi Linda,


> Did you mean more than that?

Yes, a bit more:

All terms derived from qualified_identification_variable or composable_qualified_identification_variable start with KEY, VALUE or ENTRY, respectively.

However, section 4.4.4, footnote 56 and the referred section 4.4.2 state "the use of VALUE is optional"

E.g. consider this query (modfied example from the spec, VALUE instead of KEY)

SELECT i.name, p

FROM Item i JOIN i.photos p
WHERE VALUE(p) LIKE ‘%egret’

which would now be parsable after your suggested BNF modifications, is equivalent to:

SELECT i.name, p

FROM Item i JOIN i.photos p
WHERE p LIKE ‘%egret’

which might still not be parsable, because we do only have a 'identification_variable' here, and not a 'qualified_identification_variable'.

Thank you!

Christian


On Tue, Mar 27, 2012 at 8:08 PM, Linda DeMichiel <linda.demichiel@...> wrote:
Hi Christian,

I had intended that we would treat KEY and VALUE the same in the below.

Did you mean more than that?

regards,

-Linda



On 3/27/2012 12:14 AM, Christian Romberg wrote:
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@... <mailto:linda.demichiel@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> <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> <tel:%2B49%2040%2060990-0>
                               (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113> <tel:%2B49%2040%2060990-113>
                               (E) cromberg@... <mailto:cromberg@...> <mailto:cromberg@...
                               <mailto:cromberg@...>>
                               www.versant.com <http://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.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@spree GmbH
                       Bülowstr. 66, D-10783 Berlin

                       Fon: +49 30 235 520-33 <tel:%2B49%2030%20235%20520-33>
                       Fax: +49 30 217 520-12 <tel:%2B49%2030%20217%20520-12>
                       Email: michael.bouschen@... <mailto:michael.bouschen@akquinet.de>
                       Web: www.akquinet.de <http://www.akquinet.de> <http://www.akquinet.de>


                       akquinet tech@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@spree GmbH
               Bülowstr. 66, D-10783 Berlin

               Fon: +49 30 235 520-33 <tel:%2B49%2030%20235%20520-33>
               Fax: +49 30 217 520-12 <tel:%2B49%2030%20217%20520-12>
               Email: michael.bouschen@... <mailto:michael.bouschen@akquinet.de>
               Web: www.akquinet.de <http://www.akquinet.de> <http://www.akquinet.de>


               akquinet tech@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@spree GmbH
       Bülowstr. 66, D-10783 Berlin

       Fon: +49 30 235 520-33 <tel:%2B49%2030%20235%20520-33>
       Fax: +49 30 217 520-12 <tel:%2B49%2030%20217%20520-12>
       Email: michael.bouschen@... <mailto:michael.bouschen@akquinet.de>
       Web: www.akquinet.de <http://www.akquinet.de> <http://www.akquinet.de>


       akquinet tech@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@... <mailto:cromberg@...>
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.






--
Christian Romberg
Chief Engineer | Versant GmbH
(T) +49 40 60990-0
(F) +49 40 60990-113
(E) cromberg@...
www.versant.com | www.db4o.com


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







--
Christian Romberg
Chief Engineer | Versant GmbH
(T) +49 40 60990-0
(F) +49 40 60990-113
(E) cromberg@...
www.versant.com | www.db4o.com

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






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

Christian Romberg 06/14/2012

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

Linda DeMichiel 06/19/2012

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

Christian Romberg 06/22/2012

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

Linda DeMichiel 06/22/2012

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

Michael Bouschen 06/22/2012

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

Christian Romberg 06/25/2012
 
 
Close
loading
Please Confirm
Close