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&gt; написал: > 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&gt; > 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

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&gt;: > 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&gt; > 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&gt; написал: >> >> > 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&gt; >> > 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 > >

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(a)hibernate.org&gt; wrote: > Sanne, Gunnar any thoughts/input here? > > > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk(a)gmail.com&gt; > 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&gt;: >> >>> 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&gt; >>> 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&gt; написал: >>>> >>>> > 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&gt; >>>> > 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 >>> >>> >>

Sanne, Gunnar any thoughts/input here? On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk(a)gmail.com&gt; 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&gt;: > >> 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&gt; >> 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&gt; написал: >>> >>> > 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&gt; >>> > 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

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&gt; 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&gt; wrote: > > Sanne, Gunnar any thoughts/input here? > > > > > > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk(a)gmail.com&gt; > > 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&gt;: > >> > >>> 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&gt; > >>> 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&gt; написал: > >>>> > >>>> > 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&gt; > >>>> > 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

I am about to push all this upstream. It now includes a hook through EntityPersister via a newly added method and "parameter object": List multiLoad(Serializable[] ids, SessionImplementor session, MultiLoadOptions loadOptions); MultiLoadOptions encapsulates the information configured on MultiIdentifierLoadAccess. At this point, I am calling this work done. On Mon, Jan 25, 2016 at 12:30 PM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > I like "multiLoad". Makes the intent more explicit, as the method > could be abused by passing lists of singleton identifiers. > > On 25 January 2016 at 18:21, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > 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&gt; > 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&gt; > wrote: > >> > Sanne, Gunnar any thoughts/input here? > >> > > >> > > >> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov < > bulanovk(a)gmail.com&gt; > >> > 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&gt;: > >> >> > >> >>> 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&gt; > >> >>> 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&gt; написал: > >> >>>> > >> >>>> > 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&gt; > >> >>>> > 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 >