EJBQL Question (HFE page 434)

[Jeff Shelley]

I'm a little confused.
For those who don't have "the book", there's a question that goes like this on page 434 (number 12):
"Given CMP beans CustomerBean, OrderBean and LineItemsBean with the following relationships:
CustomerBean(1) <--> OrderBean(n)
OrderBean(1) <--> LineItemsBean(n)
Which will return all orders that have line items? (Choose all that apply.)
A. SELECT DISTCINT o from Order o, IN( o.lineItems) li
B. SELECT DISTINCT OBJECT(o) From Order o, IN(o.lineItems) li
C. SELECT OBJECT(o) FROM Order o Where o.lineItems = 0
D. SELECT OBJECT(o) FROM Order o
The book says that both B and D are valid, but I'm a little confused about D. Is my confusion because of semantics (all orders include all orders with line items) or a concept I'm not grasping?
Thanks for your help!
--Jeff

[David Harrigan]

Hi,
Good question. I believe what is mis-leading is the use of the <--> arrows (which to me, on first glance means bi-directional, n-m relationship). What I had to look for was the (1) and the (n). Looking at the spec, and at the question, to me D is incorrect!
Basically, what it is saying is that:
An Order can contain many LineItemsBeans
i.e., it's a 1 to Many relationship.
So, to explain the answers.
Why is A incorrect?
Because it doesn't have Object(o), and we are selecting objects.
Why is B correct?
It is correct because the select is finding all objects from all the orders out there that are of type lineitems.
Why is C incorrect?
That would return Orders that /dont/ have lineItems.
Why is D incorrect?
According to the spec, this select will simply return all OrderBeans, with no qualification that they must contain lineItems. So it would be my understanding that some of the OrderBeans return could contain lineItems and some may not...
Perhaps someone could clarify this?
-=david=-

[Goan Balchao]

I agree with you (the last point) David. A similar example is also given in the spec - in the QL chapter.
But I have a question of my own.. here
Option:
SELECT OBJECT(o) FROM Order o Where o.lineItems = 0
Your answer :
Why is C incorrect?
That would return Orders that /dont/ have lineItems
Would this be correct :- o.lineitems = 0. For CMR's, the Order to LineItems relationship would be a Collection of LineItems in Order.
For an Order that has no Line Items, the Collection of Line Items would be null. SO does the QL translate this o.lineItems = 0 to an expression of the type if(o.getLineItems == null) .. ?
I mean shouldn't it be o.lineItems = NULL ?

[David Harrigan]

Hi,
I believe that if a select method doesn't find anything then the collection returned is not null, but simply empty, i.e., size() returns 0.
This is alluded to on page 233 of Enterprise JavaBeans by Richard Monson-Haefel (top of the page).
-=david=-

[Keith Rosenfield]

I noticed this issue a couple weeks back and sent an email to Kathy regarding this. She hasn't responded to this particular issue yet.
The way d reads
SELECT OBJECT(o) FROM Order o
it will return all orders without regard to number of lineitems that it
may be related to.
The way d should read in order to be correct is
SELECT OBJECT(o) FROM Order o WHERE o.lineitems IS NOT EMPTY
in which case it will return only orders that have associated lineitems.
This is precisely the query that is described in section 11.3.2 of the specification.
Hope this helps.

[carlos fernandez]

David Wrote:
--> Why is B correct? It is correct because the select is finding all objects from all the orders out there that are of type lineitems.
I am struggling to understand the meaningful difference between answers B and D in this question.
As i understand it by adding "IN (o.lineItems) li" the EJB-QL statement in answer B, the EJB-QL is simply making the elements in the lineItems collection available as the identification variable "li". It would take another path expression in the WHERE clause to access the elements exposed by "li".
Since I have a SQL background I unfortunately still tend to think about this in SQL terms. It is my understanding that "IN (o.lineItems)" returns the related objects as a separate "table" known as "li". But unless you run any where clause expressions on the elements returned in "li" you won't know if there are matching objects or not.
The only reason that B and D could be correct is because (n) denotes a 1 to many relationship instead of a zero to many. Is that correct? If that is true then all Orders must have at least one LineItem, which makes sense. Which is the only way that D could be correct.

[Roger Chung-Wee]

(n) surely denotes a zero to many relationship. I believe that answer D should not have been checked unless the EJB-QL looks like what Keith suggests.

[raphael Bereh]

I might be wrong, but I consider the multiplicity (n) in this case to be 1,n
The reason for that being (in the real world) you don't get an Order for NOTHING ! In other words an Order oders a least One (1) Item.
With this view, if you have an Order, then, there is a least one lineItem for the Order ! So Selecting all Order id a Good query !?!

[raphael Bereh]

OooopS
Please read (from : http://www.oreilly.com/catalog/hfjejb/errata/hfjejb.unconfirmed):
[434] Question 12;
Answer D is incorrect.
The question is "Which will return all orders that have line items ?".
D = SELECT OBJECT(o) FROM Order o
Or there is a missing "WHERE NOT o.lineItems IS EMPTY" or D should be unchecked.