Hi all, I have been off the radar for too long I am working on a requirement at $DAYJOB where there is a desire to monitor the rate of low and zero result queries, as such I did the simplest thing I could think of and wrote a search component that looks through the response object in the later phases of a distributed request.
As I was doing this it struck me how inconsistent it is to find the "total number of hits" for a given search query, even if the response is manipulated heavily after the fact shouldn't we make it easier for people writing things like search components / transformers etc to find out how many matches they had ? This is where I started to wonder if it makes sense to hide / elide the original usage of totalHitCount as part of grouping, and use this field for presenting some sensible number of matches for the query; I know that this might break backwards compat with people who look at this field, but then I figure it is very ambiguously named so many naive users are likely to use this field not realizing that it is all about grouping. I am probably going to craft a patch to this end, unless someone has any intuition that I am missing here -- Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
