> > 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();

> This is something I could have made use of sometimes either.

> In fact, today I query the Order.class and build the map manually then
> by walking through the list in a first pass and fetch the customer
> property.

> Hmmm .... and when I think of, it often gets even more complicated and
> ends in something like this:

> Map<Customer, Map<DeliveryMethod, List<Order>>> resultMap = ....

> Such a result is also easily built by walking through the list in a
> first pass.

> I think it is much like the gropu by feature in sql plus keeping the
> detail data.

> Which then might look like this (I bring OrderItem in the game now):

> Map<Customer, Map<DeliveryMethod, Map<Order, List<OrderItems>>>>
> resultMap = Ebean.query(OrderItems.class).findGroups("order.customer",
> "order.deliveryMethod", "order") // el expression

> Question is if Ebean can make any use of the information (for
> performance) that it has to find a map or group, else the findGroups()
> method can also be a utility method in your application.
> With a little bit of reflection magic you can do that.

> Ciao,
> Mario