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>
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> написал:
> 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>
> 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