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?
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!).
Heck, I would *love* to see:
normalHibernateSessionFactory.openSession()
.as( EntityManager.class )
...
On 04/26/2011 01:31 AM, Sanne Grinovero wrote:
> 2011/4/25 Steve Ebersole<[email protected]>:
>> 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"<[email protected]> 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
>>>>>>> [email protected]
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>> --
>>>> Steve Ebersole<[email protected]>
>>>> http://hibernate.org
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> [email protected]
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> --
>> Steve Ebersole<[email protected]>
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
--
Steve Ebersole <[email protected]>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
