[hibernate-dev] Decoupling indexed types from their class definitions

Hardy Ferentschik hardy at hibernate.org
Mon Oct 7 06:32:47 EDT 2013


On 7 Jan 2013, at 12:06 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> It adds a bit to the
> index size, but I guess it's the safer/simpler option for the time being.

The index size difference is imo in this case negligible. I would not have been comfortable with the
required changes in Search in case we had to change the behaviour around OBJECT_CLASS.

--Hardy



> 
> 2013/10/7 Sanne Grinovero <sanne at hibernate.org>
> 
>> On 7 October 2013 10:51, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> 2013/10/7 Sanne Grinovero <sanne at hibernate.org>
>>>> 
>>>> Hi  Gunnar,
>>>> yes we've been reviewing the Infinispan Query code and it seem that
>>>> what we have today if good enough for this release cycle.
>>>> We're keeping the issues open as the current approach can use some
>>>> polish, but time-wise we need to make space for more experimentation.
>>> 
>>> 
>>> Ok, that sounds good. How will queries restricted to one user type be
>>> realized with the current implementation?
>> 
>> The current implementation doesn't expose any Lucene API, it's all
>> nicely hidden by a super-easy high level filtering API.
>> The drawback is that far less features are available to the end user,
>> but the advantage is that the Lucene Query which is internally
>> generated is never exposed, so fully controlled by the Infinispan
>> parser.
>> 
>> This is the relevant line:
>> 
>> 
>> https://github.com/infinispan/infinispan/blob/6.0.0.CR1/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/QueryFacadeImpl.java#L156
>> 
>> Sanne
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev




More information about the hibernate-dev mailing list