Hi Trejkaz, You can still use a standard collector if you don’t need to worry about multi-threaded search. It sounds as though what you want to do is implement your own Collector that will read and record docvalues hits, and use MultiCollector to wrap it and a standard TopDocsCollector together.
Alan Woodward www.flax.co.uk > On 8 Oct 2015, at 01:22, Trejkaz <trej...@trypticon.org> wrote: > > Hi all. > > I have a situation where I want to look up some DocValues for each hit > in the search. > > I have a few ways I could go about this: > > 1. Use search() as normal and then iterate the hits at the end to > collect the values (easiest?) > > 2. Use TopStoreDocsCollector, TopFieldCollector, etc. as-is and > add my own collector to run alongside them. (Only complication seems > to be that these are no longer convenient to use, because it appears > that you now have to use a CollectorManager?) > > 3. Try to extend TopStoreDocsCollector, TopFieldCollector, etc. to > return subclasses of TopDocs which already have the information in > them. > > 4. Forget about all these pre-existing collectors and write my own > collector that implements search from scratch and just collects only > the information we actually want. (In this particular case, we don't > care about docId, because aside from fetching the stable ID, there is > nothing we use this for up-front when doing a search. Removing it from > the API would be beneficial for us because it would stop people being > tempted to use the doc ID and therefore introduce bugs.) > > The value we want to fetch is essentially our stable replacement for > docId, so I figure other people's applications would have gone through > this already. What did everyone else do? > > TX > > P.S. My original workaround was to delay it until someone asks for the > hit, but if you don't get it from the exact same reader you did the > search with, you will get the wrong value sometimes. And of course, we > can't keep the reader around forever, because we have no idea when the > caller will stop using the search results object. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org >
