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
