[hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)
Steve Ebersole
steve at hibernate.org
Mon Jan 25 14:09:58 EST 2016
I am about to push all this upstream. It now includes a hook through
EntityPersister via a newly added method and "parameter object":
List multiLoad(Serializable[] ids, SessionImplementor session,
MultiLoadOptions loadOptions);
MultiLoadOptions encapsulates the information configured
on MultiIdentifierLoadAccess.
At this point, I am calling this work done.
On Mon, Jan 25, 2016 at 12:30 PM Sanne Grinovero <sanne at hibernate.org>
wrote:
> 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
>
More information about the hibernate-dev
mailing list