The AuditReader is stateful on the other hand - apart from the Session and
Envers config (which could be looked up each time), it contains a first-level
cache for already resolved historical objects.
Adam
On Apr 26, 2011, at 8:04 PM, Emmanuel Bernard wrote:
> 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 <st...@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<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
>>>>>
>>>
>>> --
>>> 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
--
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
