[hibernate-dev] multiLoad support

[Sanne Grinovero]

some comments inline:

On 25 July 2016 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> I wanted to start a consolidated discussion about multi-load support.  This
> relates to a few Jiras, questioning a few different aspects of its current
> behavior:
>
> https://hibernate.atlassian.net/browse/HHH-10984
> https://hibernate.atlassian.net/browse/HHH-10617
>
> Basically this comes down to the following questions/requests...
>
>
> ## Handling locally deleted entities
>
> First (from HHH-10984) is the idea that locally deleted entities are
> currently returned from multi-load calls.  The background here is that
> multi-load support was designed based on IdentifierLoadAccess#getReference
> (Session#load).  So its outcome follows what is done for #getReference in
> terms of behavior and results.  Now one of the behaviors of #getReference
> that differs from IdentifierLoadAccess#load (Session#get) is how locally
> deleted entities are treated: #getReference will return them, whereas #load
> will not.
>
> So as I see it we have 3 options:
>
>    1. Continue to expose just the one form on MultiIdentifierLoadAccess and
>    either have this filter out the locally deleted objects, or add a new
>    option to specify whether locally deleted objects ought to be returned in
>    the results.
>    2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
>       1. Plural form of #getReference (current behavior, more or less)
>       2. Plural form of #load
>    3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
>       1. Plural form of #getReference
>       2. Plural form of #load
>       3. "Hybrid" form

Regarding locally deleted entities, I understand the underlying logic
but as a user I think I'd be surprised for it to return them.
Is there a good use case to return these?

Failing that, I'd filter them out by resorting to a load-like semantic
and avoid giving options.


> ## Ordering of results
>
> Much of the discussion on HHH-10984 revolves around the (poorly based, imo)
> assumption that because a List/array of ids is passed in and because a List
> is returned that we ought to return the results in the order indicated by
> the incoming List/array of ids.

As discussed on chat, in lack of any explicit documentation I also
would have expected the order to be preserved, but stating otherwise
in javadoc seems good enough to me.

+1 to change the parameter type from List to Collection as you
suggested; the return should also be changed from List so to not
suggest any ordering guarantee but since that's breaking we'll do it
later.

> While I do not agree with the assumption there, I can see that that
> behavior might sometimes be beneficial.  Is this something we want to
> support?  There is certainly a performance overhead, and so I think we
> definitely do not want to support it by default.  But do we want to expose
> an option to allow users to request this?

Yes I think there would be performance benefits to allow the consumer
to push the sorting guarantee to ORM:
in worst case, ORM will do it in the same inefficient way that the
consumer would need to, but there might be cases in which ORM can do
something smarter.

In Hibernate Search we have two different situations in which we'd
load by "byMultipleIds";
in one case we'll need strict sorting, in the other we actually don't
care at all for the order.. so yes we'd benefit from an option.

Considering that the current API takes a List as parameter, and
returns a List, and that we seem to agree that there's value in
maintaining ordering.. maybe we should keep this API as is and make it
always ordered?
One could add the variation based on Collections as the alternative
API to use when ordering is not needed, by adding it as a new API we'd
not be breaking anything and still providing both options.

Thanks,
Sanne