lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Woodward <>
Subject Re: Recommendation for doing a search plus collecting extra information?
Date Sun, 11 Oct 2015 19:32:37 GMT
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

> On 8 Oct 2015, at 01:22, Trejkaz <> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message