[hibernate-dev] Integrator and retrieving objects

[Sanne Grinovero]

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