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