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

Sanne Grinovero sanne at hibernate.org
Mon Jan 25 14:22:23 EST 2016 

Looks good! Time for us to put it to good use..
Thanks

On Mon, 25 Jan 2016 19:10 Steve Ebersole <steve at hibernate.org> wrote:

> 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