[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