Re: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)

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 <steve(a)hibernate.org&gt; 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 <sanne(a)hibernate.org&gt; 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 <steve(a)hibernate.org&gt; wrote: >> > Sanne, Gunnar any thoughts/input here? >> > >> > >> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov < bulanovk(a)gmail.com&gt; >> > 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 <steve(a)hibernate.org&gt;: >> >> >> >>> 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 >> >>> <bulanovk(a)gmail.com&gt; >> >>> 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/annotatio... >> >>>> which allows us to specify our own implementation of >> >>>> >> >>>> >> >>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister... >> >>>> . >> >>>> >> >>>> >> >>>> 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" < >> >>>> notifications(a)github.com&gt; написал: >> >>>> >> >>>> > 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 < >> >>>> > notifications(a)github.com&gt; >> >>>> > 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(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >>> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev