I know what you mean, and maybe I'm just being obstinate.  But in the
general case, it isn't possible to know these things ahead of time.  The
indexing machinery isn't told about changes in user permissions (e.g.
demotion from administrative to ordinary user), and even if it were I'd hate
to have to reindex everything just to reflect that change.

Jon

> -----Original Message-----
> From: Daniel Pitts [mailto:[EMAIL PROTECTED] 
> Sent: 27 August 2007 18:10
> To: solr-user@lucene.apache.org
> Subject: RE: Filtering using data only available at query time
> 
> Can you add some fields that let set a filter or query that 
> weed out the results that the user doesn't have access too?
> 
> If its as simple as Admin versus User, you could have a 
> boolean field called AdminOnly, and when a User is querying, 
> add a fq=[* TO *] -AdminOnly:true
> 
> You could get more specific if you need to, just provide the 
> information that you would use to determine the availability 
> of the record to any given user, and then construct the 
> filter based on the current user.
> 
> > -----Original Message-----
> > From: Jonathan Woods [mailto:[EMAIL PROTECTED]
> > Sent: Monday, August 27, 2007 10:00 AM
> > To: solr-user@lucene.apache.org
> > Subject: Filtering using data only available at query time
> > 
> > I've got a Lucene-based search implementation which searches over 
> > documents in a CMS and weeds out those hits which aren't 
> accessible to 
> > the user carrying out the search.  The raw search results 
> are returned 
> > as an iterator, and I wrap another iterator around this to silently 
> > consume the inaccessible hits.  (Yes, I know... wasteful!)  
> The search 
> > is therefore based on data (user permissions) which can't 
> be known at 
> > indexing time.
> >  
> > I'm now porting the search implementation over to Solr.  I 
> took a look 
> > at FunctionQuery, and wondered if there was some way I 
> could use it to 
> > do this kind of filtering - but as far as I can tell, it's 
> only about 
> > scoring a hit
> > - ValueSource can't signal 'don't include this at all'.  Is there a 
> > case for introducing some kind of boolean include/exclude factor 
> > somewhere along the API?  Or is there another obvious way 
> to do this?  
> > I guess I could implement my own Query subclass and use it 
> as a filter 
> > [query] in the search, but I wonder if it would be still be 
> useful in 
> > FunctionQuery.
> >  
> > Jon
> >  
> > 
> 
> 
> 

Reply via email to