[hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)
Konstantin Bulanov
bulanovk at gmail.com
Wed Jan 20 03:16:28 EST 2016
Hello, Steve,
I absolutely agree with you regarding LoadEvent, but if LoadEvent will be
omitted and it will be possible to implement custom MultiIdentifierLoader, it
is better to move L2 and L1 cache support to one place, for example to
MultiIdentifierLoadAccess (right now I couldn’t find where multiLoad stack
works with L2 cache ).
So if we a goes with proposed version (MultiIdentifierLoadAccess -> (*)
EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad) it will
give a possibility to use same(customized) loader as for loading by single
id and restore framework consistent behavior.
2016-01-20 2:45 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
> 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