I guess my question is "what advantage are you trying to get here?"
At the start, this feels like an "XY" problem. How are you intending to use the fq after you've built it? Because if there's any way to just create an "fq" clause, Solr will take care of it for you. Caching it, autowarming it when searchers are re-opened, etc. Otherwise, you're going to be re-inventing a bunch of stuff it seems to me, you'll have to intercept the queries coming in in order to apply the filter from the cache, etc. Which also may be another way of asking "How big is this set of document IDs?" If it's in the 100s, I'd just go with an fq. If it's more than that, I'd index some kind of set identifier that you could create for your fqs. And if this is gibberish, ignore me <G>.. Best Erick On Tue, Apr 17, 2012 at 4:34 PM, Chris Collins <ch...@geekychris.com> wrote: > Hi, I am a long time Lucene user but new to solr. I would like to use > something like the filterCache but build a such a cache not from a query but > custom code. I guess I will ask my question by using techniques and vocab I > am familiar with. Not sure its actually the right way so I appologize if its > just the wrong approach. > > The scenario is that I would like to filter a result set by a set of labeled > documents, I will call that set L. > L contains app specific document IDs that are indexed as literals in the > lucenefield "myid". > I would imagine I could build a OpenBitSet from enumerating the termdocs and > look for the intersecting ids in my label set. > Now I have my bitset that I assume I could use in a filter. > > Another approach would be to implement a hits collector, compute a fieldcache > from that myid field and look for the intersection in a hashtable of L at > scoring time, throwing out results that are not contained in the hashtable. > > Of course I am working within the confines / concepts that SOLR has layed > out. Without going completely off the reservation is their a neat way of > doing such a thing with SOLR? > > Glad to clarify if my question makes absolutely no sense. > > Best > > C
