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

Konstantin Bulanov bulanovk at gmail.com
Tue Nov 24 03:11:39 EST 2015


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
>
>


More information about the hibernate-dev mailing list