Re: [hibernate-dev] Integrator and retrieving objects

2011/4/25 Steve Ebersole<steve(a)hibernate.org>: > 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"<adam(a)warski.org> 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<steve(a)hibernate.org> >>> 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> > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >