lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Recommendation for doing a search plus collecting extra information?
Date Thu, 08 Oct 2015 02:16:28 GMT
This may be an "XY" problem, you're asking how to do X thinking
it will solve Y without telling us what Y is.

What do you want to _do_ with the DV values you look up for each hit?


On Wed, Oct 7, 2015 at 5:22 PM, 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message