Hello Steve, now it looks great. Thank you.
2016-01-25 23:09 GMT+04:00 Steve Ebersole <st...@hibernate.org>: > 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 <sa...@hibernate.org> > 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 <st...@hibernate.org> 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 <sa...@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 <st...@hibernate.org> >> wrote: >> >> > 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
