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
