Here's the problem with what you're outlining: Solr/Lucene doc ids are NOT invariant, so the doc IDs you get from "the other system" will not be directly usable by in the filter. But assuming the other system stores what you've defined as <uniqueKey> you could walk the index and get the doc IDs from that (See TermDocs in the Lucene API documentation).
There's an extensive discussion of this here: http://lucene.472066.n3.nabble.com/filter-query-from-external-list-of-Solr-unique-IDs-td1709060.html But this sounds a lot like this patch (I've only skimmed the comments, so I may be off base): https://issues.apache.org/jira/browse/SOLR-2272 note that this is a patch that I don't think has been committed yet, so you'd have to get the source, apply the patch and then use it. See: http://wiki.apache.org/solr/HowToContribute for instructions here. Best Erick On Wed, Dec 15, 2010 at 9:49 AM, Michael Owen <michaelowe...@hotmail.com>wrote: > > Hi all, > I'm currently using Solr and I've got a question about filtering on a lower > level than filter queries. > We want to be able to restrict the documents that can possibly be returned > to a users query. From another system we'll get a list of document unique > ids for the user which is all the documents that they can possibly see (i.e. > a base index list as such). The criteria for what document ids get returned > is going to be quite flexible. As the number of ids can be up to index size > - 1 (i.e. thousands) using a filter query doesn't seem right for entering a > filter query which is so large. > Can something be done at a lower level - perhaps at a Lucene level - as I > understand Lucene starts from a bitset of possible documents it can return - > could we AND this with a filter bitset returned from the other system? Would > this be a good way forward? > And then how would you do this in Solr with still keeping Solr's extra > functionality it brings over Lucene. A new SearchHandler? > Thanks > Mike > > > > > >
