Ah, I see. So ISPN is using a custom field holding the user type name and filtering on that one instead of using the existing OBJECT_CLASS field. That was the missing puzzle piece I was looking for :) It adds a bit to the index size, but I guess it's the safer/simpler option for the time being.
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
