[hibernate-dev] Integrator and retrieving objects
Emmanuel Bernard
emmanuel at hibernate.org
Tue Apr 26 14:04:52 EDT 2011
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 <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
>>
More information about the hibernate-dev
mailing list