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

[Steve Ebersole]

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
>