The queries are generally BooleanQuery combinations of TermQueries, sometimes with output from the vanilla Lucene QueryParser thrown in as one of the boolean clauses: "get me all pages about the Senior School && about drama [that's the fq bit], hopefully also containing the word 'Shakespeare'". The index is made up using Documents which each correspond to a resource in a CMS, so I also index each resource's path (in CMS-space).
At the moment I get the results as an iterator over hits; I wrap that in a filtering iterator which gets each Hit's Document's resource path field, and uses the CMS to test whether the searching user can access the corresponding resource, swallowing the iteration if not. Effective hit counts are worked out the same way. No performance problems yet, but it feels like a waste! The ideal would be if there were a AccessibleToCurrentUserQuery, i.e. FunctionQuery where function evaluation happens to involve a CMS accessibility check. Going the Filter route at all isn't easy in any case, because my CMS won't (easily) tell me when user permissions have changed - so I can't tell when it's necessary to invalidate the cache. Jon > -----Original Message----- > From: Yonik Seeley [mailto:[EMAIL PROTECTED] > > On 9/6/07, Jonathan Woods <[EMAIL PROTECTED]> wrote: > > As a quick sideline to the discussion on FunctionQueries > (which is way > > beyond me): would it not be useful for a FunctionQuery to > be able to > > exclude hits (using that term loosely) as well as to affect their > > score? Can/should the current framework do that? > > > > I ask because I want to exclude hits on the basis of their > > availability, where 'availability' is to do with user > permissions and <snip> > > Can you give examples of what the queries look like (assuming > they are expressible in lucene query syntax)? > > fq params often work pretty well since they are cached and > reused (hence the cost of going across the whole index is > only paid once). A FunctionQuery would have some of the same > issues... building the FieldCache entry the first time is > relatively expensive. > > -Yonik > > >
