The direct link to DynamicBatchingEntityLoaderBuilder makes it fail with OGM; So yes, going through EntityPersister for obtaining the right loader would be great so we can make multi-id-load work with OGM.
2016-01-19 23:30 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > Sanne, Gunnar any thoughts/input here? > > > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulan...@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 <st...@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 <bulan...@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" < >>>> notificati...@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 < >>>> > notificati...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
