[hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)

[Sanne Grinovero]

I like "multiLoad". Makes the intent more explicit, as the method
could be abused by passing lists of singleton identifiers.

On 25 January 2016 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
> Minor detail wrt method naming...
>
> Actually performing a org.hibernate.MultiIdentifierLoadAccess is currently
> achieved via a method named `#multiLoad`.  The name was chose because
> originally I wanted this to live on IdentifierLoadAccess and so the `multi`
> part was needed to distinguish it from the singular load form.
>
> Now that this has been split off into a new contract, is maybe
> MultiIdentifierLoadAccess#load preferable over
> MultiIdentifierLoadAccess#multiLoad?
>
> On Wed, Jan 20, 2016 at 3:46 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Steve,
>> Hibernate Search doesn't customize the loaders: if any we want to make
>> sure that whatever customization has been defined is being used by
>> Search as well.
>> Hibernate OGM does of course replace the default loaders; I'm not sure
>> how nicely that interacts with the user wanting to override it.
>>
>> -- Sanne
>>
>> On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org> wrote:
>> > Sanne, Gunnar any thoughts/input here?
>> >
>> >
>> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
>> > wrote:
>> >
>> >> Hello, yes, you are absolutely right, the main concern here is that
>> >> with
>> >> new MultipleLoad API we got inconsistent behavior for loading using
>> >> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>> >>
>> >>
>> >> What regarding my case, it is loading data from EAV model, with
>> >> predefined
>> >> scenarios.
>> >>
>> >>
>> >> We have 3 tables:
>> >>
>> >>
>> >> Objects[id – pk, name, type_id, parent]
>> >> Params[attr_id, value, object_id (fk to objects), show_order]
>> >> References[ attr_id, reference, object_id( fk to objects), show_order]
>> >>
>> >>
>> >> Also we have a data loading scenario configuration based on type_id,
>> >> identifying set of params\references Entities and Object Entities
>> >> referenced by References entity to be Eager load during loading Object
>> >> Entities.
>> >>
>> >>
>> >> We have more than 1k attributes and more than 100Gb of data in
>> >> Object\Params\References entities
>> >>
>> >>
>> >> So it is simple recursive loading task, as per me, the best place for
>> >> it
>> >> persister.load with optimized loader (at least without query hardparse
>> >> on
>> >> each multiloading, this could be done using custom Oracle\PostgreSQL
>> >> datatype to pass array of ids as a bind variable in case of bulk load
>> >> by
>> >> Ids)
>> >>
>> >>
>> >> PostgreSQL ex.:
>> >> Select * from objects where id = any(?);
>> >>
>> >>
>> >> If you could advise better solution to implement such scenario based on
>> >> EAV Eager loading I will be very appreciated to you.
>> >>
>> >> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>> >>
>> >>> Personally I think its a questions of semantics; to me a multi-id load
>> >>> already implies/indicates a certain loading strategy (Loader).  You
>> >>> are
>> >>> saying you'd like the ability to still decide a specific loading
>> >>> strategy
>> >>> for multi-id loads.  I seriously doubt that is really what you want,
>> >>> but I
>> >>> do understand the desire for consistency.  Maybe some others will
>> >>> chime in;
>> >>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in
>> >>> terms
>> >>> of integrating this with Search.
>> >>>
>> >>> Also, that was not the question I asked.  Specifically, what is it you
>> >>> want to do that you cannot do given the current call chain?
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov
>> >>> <bulanovk at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>> >>>> mail
>> >>>> list.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Regarding you question, in current architecture and implementation we
>> >>>> have
>> >>>> the following point to perform entity persistence customization.
>> >>>>
>> >>>> Annotation:
>> >>>>
>> >>>>
>> >>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>> >>>> which allows us to specify our own implementation of
>> >>>>
>> >>>>
>> >>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>> >>>> .
>> >>>>
>> >>>>
>> >>>> One of its methods is:
>> >>>>
>> >>>>
>> >>>>
>> >>>> Object load(Serializable id,
>> >>>>
>> >>>>             Object optionalObject,
>> >>>>
>> >>>>             LockMode lockMode,
>> >>>>
>> >>>>             SessionImplementor session)
>> >>>>
>> >>>>      throws HibernateException
>> >>>>
>> >>>>
>> >>>>
>> >>>> Load an instance of the persistent class.
>> >>>>
>> >>>>
>> >>>>
>> >>>> and
>> >>>>
>> >>>>
>> >>>>
>> >>>> Object load(Serializable id,
>> >>>>
>> >>>>             Object optionalObject,
>> >>>>
>> >>>>             LockOptions lockOptions,
>> >>>>
>> >>>>             SessionImplementor session)
>> >>>>
>> >>>>      throws HibernateException
>> >>>>
>> >>>>
>> >>>>
>> >>>> Load an instance of the persistent class.
>> >>>>
>> >>>>
>> >>>>
>> >>>> These two methods allows to specify you own Loader implementation to
>> >>>> load
>> >>>> Entity by IDS,
>> >>>>
>> >>>> in mentioned issue this part of contract was ignored by changing call
>> >>>> sequence on loading by multiple ids.
>> >>>>
>> >>>>
>> >>>>
>> >>>> By Single id;
>> >>>>
>> >>>>
>> >>>>
>> >>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>> >>>>
>> >>>>
>> >>>>
>> >>>> By Multiple id:
>> >>>>
>> >>>>
>> >>>>
>> >>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>> >>>>
>> >>>>
>> >>>>
>> >>>> So in new API for multiple load we lose at least 2 possible extension
>> >>>> points: onLoadEvent, Persister.load (here we could customize loader -
>> >>>> specify our own instead hardcoded one)
>> >>>>
>> >>>>
>> >>>>
>> >>>> From my point of view there should be the same approach to get
>> >>>> entities
>> >>>> by
>> >>>> ID(independent multiple or single).
>> >>>>
>> >>>>
>> >>>> So which one approach is correct and future-proof for Single id or
>> >>>> Multiple
>> >>>> Ids?
>> >>>>
>> >>>>
>> >>>> 20 нояб. 2015 г. 18:19 пользователь "Steve Ebersole" <
>> >>>> notifications at github.com> написал:
>> >>>>
>> >>>> > Customize how? Loader still calls into the persister. Persisters
>> >>>> > and
>> >>>> > Loaders have a back-and-forth synergy.
>> >>>> >
>> >>>> > Also please discuss this on the hibernate-dev mailing list so
>> >>>> > others
>> >>>> can be
>> >>>> > involved.
>> >>>> >
>> >>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>> >>>> > notifications at github.com>
>> >>>> > wrote:
>> >>>> >
>> >>>> > > Hello Steve, could you be so kind to advice why we have different
>> >>>> > behavior
>> >>>> > > for loading by single id and multiple ids?
>> >>>> > >
>> >>>> > > In Case of single id, loading is going through
>> >>>> > > session->IdentifierLoadAccess->event->persister->Loader
>> >>>> > > In Case of multiple ids, loading is going through
>> >>>> > > session->MultiIdentifierLoadAccess->Loader
>> >>>> > >
>> >>>> > > So in case of load by single id it is possible to cutomize
>> >>>> > > loading of
>> >>>> > > Entify using persister, but in new introduced API we lost this
>> >>>> > posibility.
>> >>>> > >
>> >>>> > > —
>> >>>> > > Reply to this email directly or view it on GitHub
>> >>>> > > <
>> >>>> >
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>> >>>> > >
>> >>>> > > .
>> >>>> > >
>> >>>> >
>> >>>> > —
>> >>>> > Reply to this email directly or view it on GitHub
>> >>>> > <
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>> >>>> >
>> >>>> > .
>> >>>> >
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev