lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Woodward <a...@flax.co.uk>
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
www.flax.co.uk


> On 8 Oct 2015, at 01:22, Trejkaz <trejkaz@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
> 


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