Re: [hibernate-dev] Integrator and retrieving objects

To clarify, FullTextSession is stateless besides holding a pointer to the Session(Implementor). so we would be fine by creating a new FullTextSession object every time as() is called. On 26 avr. 2011, at 19:47, Sanne Grinovero wrote: > 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 >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev