Re: [hibernate-dev] Integrator and retrieving objects

2011/4/26 Steve Ebersole <steve(a)hibernate.org&gt;: > as(...) is on Session though. What I am talking about is what happens when > they *somehow* get a normal Session and call session.as( > FullTextSession.class ) ? > > e.g. > > fullTextSession.getSessionFactory() > .openSession() > .as( FullTextSession.class ); > > Now what? Let's assume we also have a service called "SessionAsHandler", which contains a map of factories, where the key is the target class (like FullTextSession.class ) The "as" implementation could look into the SessionAsHandler, perform then get(FullTextSession.class).create( this ); where: - this is the current SessionImplementor - the return type is a FullTextSession instance And when the SearchService is created, it configures this additional service as well to handle the new type. > > I guess this really gets to the intent of as(...). > > Like I can see the usefulness of "light binding" the notions of a Session > and a FullTextSession (not so sure wrt AuditReader, I'd have to understand > the relation there a little better) such that the following is valid: > > normalHibernateSessionFactory.openSession() > .as( FullTextSession.class ) > .<handle yo search biz>() > > But there are a lot of implications there. Like we need to be able to make > the SessionFactory aware of the other "sub factories" and track the "sub > sessions" per Session (lazily!). I'm not sure I follow here about tracking and lazily. Why should you track the "sub sessions"? In case of Search, the FullTextSession.close() will close it's own resources and close the underlying Session as well; I think it's enough for the SessionFactory to track the standard Session and doesn't need to worry about more resources. > > Heck, I would *love* to see: > normalHibernateSessionFactory.openSession() > .as( EntityManager.class ) > ... but then the EntityManager would be able to behave according to JPA spec? I'm referring for example to the different kind of eventlisteners needed, as Emmanuel mentioned at the meeting today. Still this example is so cool, it could be worthwhile to reconsider some of the meeting thoughts. Would you expect the EntityManager to be closed if I closed the Session? And flush, other operations? according to which spec shall it behave? Cheers, Sanne > On 04/26/2011 01:31 AM, Sanne Grinovero wrote: >> >> 2011/4/25 Steve Ebersole&lt;steve(a)hibernate.org&gt;: >>> >>> Just to circle back to this (because my memory is so short).. >>> >>> What did we ever decide about this, especially in regards to the *how*? >>> >>> As and example, lets look at Search. Search wraps Session in a >>> FullTextSession. Search would register some handler with the >>> SessionFactory that says it knows how to handle Session.as( >>> FullTextSession.class ) calls. But what exactly is this handler going >>> to do? Unless Search maintains some global Session instance -> >>> FullTextSession instance... Or are you thinking the registration >>> happens per-Session? >> >> The entry points for Search are two: >> - the session *EventListener(s) (only one instance, but listening to >> multiple types of events) >> - the FullTextSession >> >> A FullTextSession needs a reference to the current session, and a >> reference to the SearchFactoryImplementor, which is the heavy-weight >> global component, similar to a SessionFactory. >> >> Currently a FullTextSession implements Session and is created from the >> Session it wraps using a static helper which searches for it's own >> PostInsertEventListener in the Session itself, from which it takes a >> reference to the needed SearchFactoryImplementor. >> >> I would be a nice improvement if the "as( FullTextSession.class )" >> implementation could retrieve the SearchFactoryImplementor from the >> ServiceRegistry instead. >> >> In pseudo code, the "as" implementation for search would look like >> something as: >> >> FullTextSession createFullTextSession() { >> return new FullTextSession( Session current, serviceRegistry.get( >> SearchFactoryImplementor.class ) ); >> } >> >> (or even simpler if SessionImplementor makes it possible to retrieve >> services ) >> >> Regards, >> Sanne >> >>> >>> >>> On 04/06/2011 09:28 AM, Emmanuel Bernard wrote: >>>> >>>> yes as is indeed better. >>>> >>>> On 6 avr. 2011, at 13:29, Steve Ebersole wrote: >>>> >>>>> A phrase I see a lot here is "as": >>>>> >>>>> session.as( AuditReader.class ).someEnversSpecificMethod() >>>>> >>>>> or >>>>> >>>>> session.as( FullTextSession.class )... >>>>> >>>>> >>>>> On 04/06/2011 06:26 AM, Adam Warski wrote: >>>>>> >>>>>> On Apr 6, 2011, at 1:20 PM, Steve Ebersole wrote: >>>>>> >>>>>>> The phrase 'unwrap' might be a bit misleading there because you may >>>>>>> not be dealing with wrapped objects. But the idea itself is still solid I >>>>>>> believe. Think of it more as a multi-directional cast >>>>>> >>>>>> Right, the idea sounds good; so it would be something like a >>>>>> per-session service? :) >>>>>> Envers could use it as well, right now just as search has >>>>>> Search.getFullTextSession, envers has AuditReaderFactory.getFor >>>>>> So we could have session.service(AuditReader.class / >>>>>> FullTextSession.class). >>>>>> >>>>>> Adam >>>>>> >>>>>>> On Apr 6, 2011 6:15 AM, "Adam Warski&quot;&lt;adam(a)warski.org&gt; wrote: >>>>>>>> >>>>>>>>> FullTextSession ftSession = session.unwrap(FullTextSession.class); >>>>>>>>> //the current approach is via some static helper method >>>>>>>>> //FullTextSession ftSession = Search.getFullTextSession(session); >>>>>>>>> >>>>>>>>> That would mean that the integration point between HSearch and >>>>>>>>> Hibernate would have an unwrap method and Hibernate would delegate the >>>>>>>>> unwrap calls to each integrator until a non null object is returned. >>>>>>>>> >>>>>>>>> It's just a thought, WDYT? >>>>>>>> >>>>>>>> But while EntityManager wraps a Session object, a Session doesn't >>>>>>>> wrap a FullTextSession, but the other way round, no? >>>>>>>> >>>>>>>> -- >>>>>>>> Adam Warski >>>>>>>> http://www.warski.org >>>>>>>> http://www.softwaremill.eu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>>> -- >>>>> Steve Ebersole&lt;steve(a)hibernate.org&gt; >>>>> http://hibernate.org >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> -- >>> Steve Ebersole&lt;steve(a)hibernate.org&gt; >>> http://hibernate.org >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > -- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org >