Skip to main content

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

  • From: Michael Bouschen <michael.bouschen@...>
  • To: <jsr338-experts@...>
  • Subject: [jsr338-experts] Re: BNF question: how to parse the example containing KEY, VALUE (and LIKE)
  • Date: Mon, 26 Mar 2012 23:14:25 +0200
  • Organization: akquinet tech@spree GmbH

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





--
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@...
Web: 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
Fax:   +49 30 217 520-12
Email: michael.bouschen@...
Web: 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
Fax:   +49 30 217 520-12
Email: michael.bouschen@...
Web:   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


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

Christian Romberg 03/19/2012

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

Linda DeMichiel 03/19/2012

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

Michael Bouschen 03/19/2012

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

Linda DeMichiel 03/19/2012

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

Michael Bouschen 03/22/2012

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

Linda DeMichiel 03/23/2012

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

Michael Bouschen 03/26/2012

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

Linda DeMichiel 03/26/2012

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

Christian Romberg 03/27/2012

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

Linda DeMichiel 03/27/2012

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

Christian Romberg 03/28/2012
 
 
Close
loading
Please Confirm
Close