On 7 Jan 2013, at 12:06 PM, Gunnar Morling <gunnar(a)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(a)hibernate.org>
> On 7 October 2013 10:51, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>> 2013/10/7 Sanne Grinovero <sanne(a)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/remo...
>
> Sanne
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev