[hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)
Steve Ebersole
steve at hibernate.org
Tue Jan 19 17:45:57 EST 2016
Konstantin, I am not sure what you are asking exactly, mainly in your last
email..
>From your first reply it sounded like you just wanted the call stack here
to route through EntityPersister (MultiIdentifierLoadAccess ->
EntityPersister -> [some-multi-id-load-loader]) rather than directly going
to DynamicBatchingEntityLoader (MultiIdentifierLoadAccess ->
DynamicBatchingEntityLoader).
That is certainly something I am willing to consider.
You had mentioned LoadEvent(Listener); personally I don't see the argument
for having a new event/listener for this. It would be consistent,
certainly, but I am just not sure what we'd gain.
So I can specifically see the calls here going MultiIdentifierLoadAccess ->
(*) EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad
[*] - new method/contract
On Tue, Jan 19, 2016 at 4:30 PM 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
>>>
>>>
>>
More information about the hibernate-dev
mailing list