Skip to main content

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

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr338-experts@..., Christian Romberg <cromberg@...>
  • Cc: Michael Bouschen <michael.bouschen@...>
  • Subject: [jsr338-experts] Re: BNF question: how to parse the example containing KEY, VALUE (and LIKE)
  • Date: Tue, 19 Jun 2012 09:54:23 -0700
  • Organization: Oracle Corporation

Hi Christian,

I thought I had fixed this in the spec draft I had uploaded a couple of weeks 
ago.
On closer inspection, it looks like I had garbled the editing.  Please have a 
look
at the revised version which I just uploaded.

thanks,

-Linda


On 6/14/2012 5:23 AM, Christian Romberg wrote:
Hi Linda,

Any update on the issue below?

Thank you!

Christian

On Wed, Mar 28, 2012 at 9:30 AM, Christian Romberg <cromberg@... 
<mailto: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 <http://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 <http://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@... 
<mailto: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@...> <mailto:linda.demichiel@__oracle.com
            <mailto:linda.demichiel@...>>> 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> <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>
            <tel:%2B49%2040%2060990-0>
                                            (F) +49 40 60990-113 
<tel:%2B49%2040%2060990-113>
            <tel:%2B49%2040%2060990-113> <tel:%2B49%2040%2060990-113>
                                            (E) cromberg@... 
<mailto:cromberg@...>
            <mailto:cromberg@... ;<mailto:cromberg@...>> <mailto:cromberg@...
            <mailto:cromberg@...>
            <mailto:cromberg@... ;<mailto:cromberg@...>>>
            www.versant.com <http://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>
            
<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.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=__AFrqEzdo3Q40RwKQPBtnPIuBYQd1di__FxJQ>

            
<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> <tel:%2B49%2030%20235%20520-__33>
                                    Fax: +49 30 217 520-12 
<tel:%2B49%2030%20217%20520-12> <tel:%2B49%2030%20217%20520-__12>
                                    Email: michael.bouschen@... 
<mailto:michael.bouschen@...>
            <mailto:michael.bouschen@__akquinet.de ;
<mailto:michael.bouschen@...>>
                                    Web: www.akquinet.de <http://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> 
<tel:%2B49%2030%20235%20520-__33>
                            Fax: +49 30 217 520-12 <tel:%2B49%2030%20217%20520-12> 
<tel:%2B49%2030%20217%20520-__12>
                            Email: michael.bouschen@... 
<mailto:michael.bouschen@...>
            <mailto:michael.bouschen@__akquinet.de ;
<mailto:michael.bouschen@...>>
                            Web: www.akquinet.de <http://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> 
<tel:%2B49%2030%20235%20520-__33>
                    Fax: +49 30 217 520-12 <tel:%2B49%2030%20217%20520-12> 
<tel:%2B49%2030%20217%20520-__12>
                    Email: michael.bouschen@... <mailto:michael.bouschen@...>
            <mailto:michael.bouschen@__akquinet.de ;
<mailto:michael.bouschen@...>>
                    Web: www.akquinet.de <http://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 <tel:%2B49%2040%2060990-0>
            (F) +49 40 60990-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.






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





[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