On Mar 5, 5:00 pm, Rob Bygrave <robin.bygr...@gmail.com> wrote:

Yes, OpenJPA just slaps the DISTINCT on to the beginning of the query.
I haven't analyzed the query to determine why this doesn't work.

The results contain 2 copies of the user, but I'm sure the 2 are the
same instance. I'll modify the unit test when I get a chance to show
this.

I've really had a hard time trying to decide what side of this I want
to be on. I've decided I do not want the child list filtered. In SQL
you have complete control over all the result rows. You get to put
things together however you want. With Ebean ORM queries you are
asking for a collection of an entity. You are not responsible for the
"intermediate" child rows. You don't "see" them or "process" them. So
the "sense" is that you are only working with the root entity rows.
Therefore the criteria should refer to these rows only.

We talked about the case of Customers and Orders. I suggested
selecting Orders rather than Customers which leads to the problem of
organizing Orders by Customers. It seems like (a variation of?)
query.findMap() could take care of this:

query = Ebean.find(Order.class)...
query.setMapKey("customer");
Map<Customer, List<Order>> resultMap = query.findMap();

 /Daryl