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
