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(a)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(a)hibernate.org> wrote:
> Sanne, Gunnar any thoughts/input here?
>
>
> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk(a)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(a)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(a)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/annotatio...
>>>> which allows us to specify our own implementation of
>>>>
>>>>
https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister...
>>>> .
>>>>
>>>>
>>>> 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(a)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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev