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

[Steve Ebersole]

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