This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
please view the comma (,) in the following EJB-QL expression with IN operator from HFEJB p.415:
I wonder whether the comma is a typo or is rightful . I can think of that the comma is correct due to the fact that we have two declarations (d AND m) in the 2nd line (FROM DirectorSchema d, IN (d.movies) m)
So IN (d.movies) m is a collection member declaration and DirectorSchema d is a range variable declaration which both can act as an identification variable declaration - which in the FROM clause are separated by commas.
In this case its confusing because it almost looks like an "english sentence". However DirectorSchema d defines the Set D of all known directors. d.movies simply defines a collection of movies for any particular director - what we need is the Set M of movies by all directors which is described through IN (d.movies) m.
So in effect the FROM clause is saying FROM Set D, Set M. (I chose capital D and M here because the d and m are used in the WHERE clause to refer to any single element from those Sets).
Conceptually the IN operator builds this Set by dumping all the movies reachable for all directors into one big Set. (See page 225; 188.8.131.52 Collection member declarations).
Mapping the example in the spec on page 224:
In the FROM clause declaration IN(d.movies) m, the identification variable m evaluates to any Movie value directly reachable from Director. The cmr-field movies is a collection of instances of the abstract schema type Movie and the identification variable m refers to an element of this collection. The type of m is the abstract schema type of Movie.
Hope this helps somehow.
I've used SQL for years but even after reading the Exam Study Kit and HFEJB I still had to read the entire chapter 11 in the specification to be less confused. In SQL, relations are either directly identified in JOINs or the WHERE clause (even though the foreign key relationship may already be defined in the RDBMS) - so this extra syntactic sugar to make use of pre-existing relationships was a bit jarring.
I'd imagine that query neophytes would be even more disturbed by the shift from the Object-Oriented to the Set paradigm. [ October 19, 2005: Message edited by: Peer Reynders ]
Joined: Aug 21, 2004
this is an incredible (wonderful ) response. Thanks a lot for this one.