Grant Ingersoll
added a comment - 07/Jan/10 16:02 Why not broaden this and allow people to pass in their own collectors?
Also, can you explain a bit more the use case specifically for Field Collapse?
Alternatively, given something like LUCENE-2127 , we may want Solr to be able to make query time decisions about what Collector to use.

Shalin Shekhar Mangar
added a comment - 07/Jan/10 19:52 Why not broaden this and allow people to pass in their own collectors?
Yes, that is the general idea, though it would be API driven than configuration. Any component should be able to pass a Collector to the various SolrIndexSearcher methods.
Also, can you explain a bit more the use case specifically for Field Collapse?
Field Collapsing needs to use a custom collector. Right now the collector is hard coded inside SolrIndexSearcher.
Alternatively, given something like LUCENE-2127 , we may want Solr to be able to make query time decisions about what Collector to use.
I guess that decision should be made by QueryComponent? If so, then the ability to pass a custom Collector to SolrIndexSearcher methods should be enough.

We've just done something like this recently and found the simplest was was to modify
ResponseBuilder with setCustomCollector / getCustomCollector,
update the QueryCommand to include the custom collector.

It gets sticky in the SolrIndexSearcher with caching, and IIRC about 4 places to call the collector, the solution works, but is not in anyway elegant.

It would be good to see if we could refactor SolrIndexSearcher first to make it more streamlined.

patrick o'leary
added a comment - 07/Jan/10 19:59 We've just done something like this recently and found the simplest was was to modify
ResponseBuilder with setCustomCollector / getCustomCollector,
update the QueryCommand to include the custom collector.
It gets sticky in the SolrIndexSearcher with caching, and IIRC about 4 places to call the collector, the solution works, but is not in anyway elegant.
It would be good to see if we could refactor SolrIndexSearcher first to make it more streamlined.

Hoss Man
added a comment - 27/May/10 22:05 Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...
http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E
Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.
A unique token for finding these 240 issues in the future: hossversioncleanup20100527

Hoss Man
added a comment - 21/Mar/12 18:09 Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently.
email notification suppressed to prevent mass-spam
psuedo-unique token identifying these issues: hoss20120321nofix36

Otis Gospodnetic
added a comment - 02/Jul/13 03:23 - edited Last comment > 1 year ago.
Patch from Martijn from 2009 and I suspect Martijn won't be working on this any more any time soon.
And does SOLR-4465 supersede this, Joel Bernstein ?
Should this be Won't Fix?