[hibernate-dev] Integrator and retrieving objects

Tue Apr 26 13:47:31 EDT 2011

2011/4/26 Steve Ebersole <steve at hibernate.org>:
> 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<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
>>>
>
> --
> Steve Ebersole <steve at hibernate.org>
> http://hibernate.org
>