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