[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-4465:
---
Fix Version/s: (was: 4.7)
4.8
> Configurable Collectors
> ---
>
> Key: SOLR-4465
> URL: https://issues.apache.org/jira/browse/SOLR-4465
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.1
>Reporter: Joel Bernstein
> Fix For: 4.8
>
> Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch
>
>
> This ticket provides a patch to add pluggable collectors to Solr. This patch
> was generated and tested with Solr 4.1.
> This is how the patch functions:
> Collectors are plugged into Solr in the solconfig.xml using the new
> collectorFactory element. For example:
>
>
> The elements above define two collector factories. The first one is the
> "default" collectorFactory. The class attribute points to
> org.apache.solr.handler.component.CollectorFactory, which implements logic
> that returns the default TopScoreDocCollector and TopFieldCollector.
> To create your own collectorFactory you must subclass the default
> CollectorFactory and at a minimum override the getCollector method to return
> your new collector.
> The parameter "cl" turns on pluggable collectors:
> cl=true
> If cl is not in the parameters, Solr will automatically use the default
> collectorFactory.
> *Pluggable Doclist Sorting With the Docs Collector*
> You can specify two types of pluggable collectors. The first type is the docs
> collector. For example:
> cl.docs=
> The above param points to a named collectorFactory in the solrconfig.xml to
> construct the collector. The docs collectorFactorys must return a collector
> that extends the TopDocsCollector base class. Docs collectors are responsible
> for collecting the doclist.
> You can specify only one docs collector per query.
> You can pass parameters to the docs collector using local params syntax. For
> example:
> cl.docs=\{! sort=mycustomesort\}mycollector
> If cl=true and a docs collector is not specified, Solr will use the default
> collectorFactory to create the docs collector.
> *Pluggable Custom Analytics With Delegating Collectors*
> You can also specify any number of custom analytic collectors with the
> "cl.analytic" parameter. Analytic collectors are designed to collect
> something else besides the doclist. Typically this would be some type of
> custom analytic. For example:
> cl.analytic=sum
> The parameter above specifies a analytic collector named sum. Like the docs
> collectors, "sum" points to a named collectorFactory in the solrconfig.xml.
> You can specificy any number of analytic collectors by adding additional
> cl.analytic parameters.
> Analytic collector factories must return Collector instances that extend
> DelegatingCollector.
> A sample analytic collector is provided in the patch through the
> org.apache.solr.handler.component.SumCollectorFactory.
> This collectorFactory provides a very simple DelegatingCollector that groups
> by a field and sums a column of floats. The sum collector is not designed to
> be a fully functional sum function but to be a proof of concept for pluggable
> analytics through delegating collectors.
> You can send parameters to analytic collectors with solr local param syntax.
> For example:
> cl.analytic=\{! id=1 groupby=field1 column=field2\}sum
> The "id" parameter is mandatory for analytic collectors and is used to
> identify the output from the collector. In this example the "groupby" and
> "column" params tell the sum collector which field to group by and sum.
> Analytic collectors are passed a reference to the ResponseBuilder and can
> place maps with analytic output directory into the SolrQueryResponse with the
> add() method.
> Maps that are placed in the SolrQueryResponse are automatically added to the
> outgoing response. The response will include a list named cl.analytic.,
> where id is specified in the local param.
> *Distributed Search*
> The CollectorFactory also has a method called merge(). This method aggregates
> the results from each of the shards during distributed search. The "default"
> CollectoryFactory implements the default merge logic for merging documents
> from each shard. If you define a different docs collector you can override
> the default merge method to merge documents in accordance with how they are
> collected at the shard level.
> With analytic collectors, you'll need to override the merge method to merge
> the analytic output from the shards. An example
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable Doclist Sorting With the Docs Collector*
You can specify two types of pluggable collectors. The first type is the docs
collector. For example:
cl.docs=
The above param points to a named collectorFactory in the solrconfig.xml to
construct the collector. The docs collectorFactorys must return a collector
that extends the TopDocsCollector base class. Docs collectors are responsible
for collecting the doclist.
You can specify only one docs collector per query.
You can pass parameters to the docs collector using local params syntax. For
example:
cl.docs=\{! sort=mycustomesort\}mycollector
If cl=true and a docs collector is not specified, Solr will use the default
collectorFactory to create the docs collector.
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of custom analytic collectors with the
"cl.analytic" parameter. Analytic collectors are designed to collect something
else besides the doclist. Typically this would be some type of custom analytic.
For example:
cl.analytic=sum
The parameter above specifies a analytic collector named sum. Like the docs
collectors, "sum" points to a named collectorFactory in the solrconfig.xml. You
can specificy any number of analytic collectors by adding additional
cl.analytic parameters.
Analytic collector factories must return Collector instances that extend
DelegatingCollector.
A sample analytic collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to analytic collectors with solr local param syntax.
For example:
cl.analytic=\{! id=1 groupby=field1 column=field2\}sum
The "id" parameter is mandatory for analytic collectors and is used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to group by and sum.
Analytic collectors are passed a reference to the ResponseBuilder and can place
maps with analytic output directory into the SolrQueryResponse with the add()
method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl.analytic.,
where id is specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different docs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With analytic collectors, you'll need to override the merge method to merge the
analytic output from the shards. An example of how this works is provided in
the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the Solr aggregator node.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.analytic=%7B!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27%7Dsum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The fi
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable doclist Sorting with the docs Collector*
You can specify two types of pluggable collectors. The first type is the docs
collector. For example:
cl.docs=
The above param points to the named collectorFactory in the solrconfig.xml to
construct the collector. The docs collectorFactorys must return a collector
that extends the TopDocsCollector base class. Docs collectors are responsible
for collecting the doclist.
You can specify only one docs collector per query.
You can pass parameters to the docs collector using local params syntax. For
example:
cl.docs=\{! sort=mycustomesort\}mycollector
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of custom analytic collectors with the
"cl.analytic" parameter. Analytic collectors are designed to collect something
else besides the doclist. Typically this would be some type of custom analytic.
For example:
cl.analytic=sum
The parameter above specifies a analytic collector named sum. Like the docs
collectors, "sum" points to a named collectorFactory in the solrconfig.xml. You
can specificy any number of analytic collectors by adding additional
cl.analytic parameters.
Analytic collector factories must return Collector instances that extend
DelegatingCollector.
A sample analytic collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to analytic collectors with solr local param syntax.
For example:
cl.analytic=\{! id=1 groupby=field1 column=field2\}sum
The "id" parameter is mandatory for analytic collectors and is used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to group by and sum.
Analytic collectors are passed a reference to the ResponseBuilder and can place
maps with analytic output directory into the SolrQueryResponse with the add()
method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl.analytic.,
where id is specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different docs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With analytic collectors, you'll need to override the merge method to merge the
analytic output from the shards. An example of how this works is provided in
the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the Solr aggregator node.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.analytic=%7B!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27%7Dsum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactor
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Attachment: SOLR-4465.patch
Changed the parameter names to be more user friendly. Description will be
updated with new parameter names shortly.
> Configurable Collectors
> ---
>
> Key: SOLR-4465
> URL: https://issues.apache.org/jira/browse/SOLR-4465
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.1
>Reporter: Joel Bernstein
> Fix For: 4.3
>
> Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch,
> SOLR-4465.patch, SOLR-4465.patch
>
>
> This ticket provides a patch to add pluggable collectors to Solr. This patch
> was generated and tested with Solr 4.1.
> This is how the patch functions:
> Collectors are plugged into Solr in the solconfig.xml using the new
> collectorFactory element. For example:
>
>
> The elements above define two collector factories. The first one is the
> "default" collectorFactory. The class attribute points to
> org.apache.solr.handler.component.CollectorFactory, which implements logic
> that returns the default TopScoreDocCollector and TopFieldCollector.
> To create your own collectorFactory you must subclass the default
> CollectorFactory and at a minimum override the getCollector method to return
> your new collector.
> The parameter "cl" turns on pluggable collectors:
> cl=true
> If cl is not in the parameters, Solr will automatically use the default
> collectorFactory.
> *Pluggable doclist Sorting with Topdocs Collectors*
> You can specify two types of pluggable collectors. The first type is the
> topdocs collector. For example:
> cl.topdocs=
> The above param points to the named collectorFactory in the solrconfig.xml to
> construct the collector. Topdocs collectorFactorys must return collectors
> that extend the TopDocsCollector base class. Topdocs collectors are
> responsible for collecting the doclist.
> You can pass parameters to the topdocs collector using local params syntax.
> For example:
> cl.topdocs=\{! sort=mycustomesort\}mycollector
> *Pluggable Custom Analytics With Delegating Collectors*
> You can also specify any number of delegating collectors with the
> "cl.delegating" parameter. Delegating collectors are designed to collect
> something else besides the doclist. Typically this would be some type of
> custom analytic.
> cl.delegating=sum
> The parameter above specifies a delegating collector named sum. Like the
> topdocs collectors, "sum" points to the named collectorFactories in the
> solrconfig.xml. You can specificy more delegating collectors by adding
> additional cl.delegating parameters.
> Delegating collector factories must return Collector instances that extend
> DelegatingCollector.
> A sample delegating collector is provided in the patch through the
> org.apache.solr.handler.component.SumCollectorFactory.
> This collectorFactory provides a very simple DelegatingCollector that groups
> by a field and sums a column of floats. The sum collector is not designed to
> be a fully functional sum function but to be a proof of concept for pluggable
> analytics through delegating collectors.
> You can send parameters to the delegating collectors with solr local param
> syntax.
> For example:
> cl.delegating=\{! id=1 groupby=field1 column=field2\}sum
> The "id" parameter is mandatory for delegating collectors and used to
> identify the output from the collector. In this example the "groupby" and
> "column" params tell the sum collector which field to groupon and sum.
> Delegating collectors are passed a reference to the ResponseBuilder and can
> place maps with analytic output directory into the SolrQueryResponse with the
> add() method.
> Maps that are placed in the SolrQueryResponse are automatically added to the
> outgoing response. The response will include a list named cl., where id
> is specified in the local param.
> *Distributed Search*
> The CollectorFactory also has a method called merge(). This method aggregates
> the results from each of the shards during distributed search. The "default"
> CollectoryFactory implements the default merge logic for merging documents
> from each shard. If you define a different topdocs collector you can override
> the default merge method to merge documents in accordance with how they are
> collected at the shard level.
> With delegating collectors, you'll need to override the merge method to merge
> the analytic output from the shards. An example of how this works is provided
> in the SumCollect
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable doclist Sorting with Topdocs Collectors*
You can specify two types of pluggable collectors. The first type is the
topdocs collector. For example:
cl.topdocs=
The above param points to the named collectorFactory in the solrconfig.xml to
construct the collector. Topdocs collectorFactorys must return collectors that
extend the TopDocsCollector base class. Topdocs collectors are responsible for
collecting the doclist.
You can pass parameters to the topdocs collector using local params syntax. For
example:
cl.topdocs=\{! sort=mycustomesort\}mycollector
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of delegating collectors with the
"cl.delegating" parameter. Delegating collectors are designed to collect
something else besides the doclist. Typically this would be some type of custom
analytic.
cl.delegating=sum
The parameter above specifies a delegating collector named sum. Like the
topdocs collectors, "sum" points to the named collectorFactories in the
solrconfig.xml. You can specificy more delegating collectors by adding
additional cl.delegating parameters.
Delegating collector factories must return Collector instances that extend
DelegatingCollector.
A sample delegating collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to the delegating collectors with solr local param
syntax.
For example:
cl.delegating=\{! id=1 groupby=field1 column=field2\}sum
The "id" parameter is mandatory for delegating collectors and used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to groupon and sum.
Delegating collectors are passed a reference to the ResponseBuilder and can
place maps with analytic output directory into the SolrQueryResponse with the
add() method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl., where id is
specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different topdocs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With delegating collectors, you'll need to override the merge method to merge
the analytic output from the shards. An example of how this works is provided
in the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the aggregator.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.delegating=%7B!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27%7Dsum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the de
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable doclist Sorting with Topdocs Collectors*
You can specify two types of pluggable collectors. The first type is the
topdocs collector. For example:
cl.topdocs=
The above param points to the named collectorFactory in the solrconfig.xml to
construct the collector. Topdocs collectorFactorys must return collectors that
extend the TopDocsCollector base class. Topdocs collectors are responsible for
collecting the doclist.
You can pass parameters to the topdocs collector using local params syntax. For
example:
cl.topdocs=\{! sort=mycustomesort\}mycollector
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of delegating collectors with the
"cl.delegating" parameter. Delegating collectors are designed to collect
something else besides the doclist. Typically this would be some type of custom
analytic.
cl.delegating=sum
The parameter above specifies a delegating collector named sum. Like the
topdocs collectors, "sum" points to the named collectorFactories in the
solrconfig.xml. You can specificy more delegating collectors by adding
additional cl.delegating parameters.
Delegating collector factories must return Collector instances that extend
DelegatingCollector.
A sample delegating collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to the delegating collectors with solr local param
syntax.
For example:
cl.delegating=\{! id=1 groupby=field1 column=field2\}sum
The "id" parameter is mandatory for delegating collectors and used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to groupon and sum.
Delegating collectors are passed a reference to the ResponseBuilder and can
place maps with analytic output directory into the SolrQueryResponse with the
add() method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl., where id is
specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different topdocs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With delegating collectors, you'll need to override the merge method to merge
the analytic output from the shards. An example of how this works is provided
in the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the aggregator.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.delegating=\{!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27\}sum&cl.delegating=\{!+id=%272%27+groupby=%27manu_id_s%27%20column=%27weight%27\}sum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.h
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable doclist Sorting with Topdocs Collectors*
You can specify two types of pluggable collectors. The first type is the
topdocs collector. For example:
cl.topdocs=
The above param points to the named collectorFactory in the solrconfig.xml to
construct the collector. Topdocs collectorFactorys must return collectors that
extend the TopDocsCollector base class. Topdocs collectors are responsible for
collecting the doclist.
You can pass parameters to the topdocs collector using local params syntax. For
example:
cl.topdocs={! sort=mycustomesort}mycollector
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of delegating collectors with the
"cl.delegating" parameter. Delegating collectors are designed to collect
something else besides the doclist. Typically this would be some type of custom
analytic.
cl.delegating=sum
The parameter above specifies a delegating collector named sum. Like the
topdocs collectors, "sum" points to the named collectorFactories in the
solrconfig.xml. You can specificy more delegating collectors by adding
additional cl.delegating parameters.
Delegating collector factories must return Collector instances that extend
DelegatingCollector.
A sample delegating collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to the delegating collectors with solr local param
syntax.
For example:
cl.delegating=\{! id=1 groupby=field1 column=field2\}sum
The "id" parameter is mandatory for delegating collectors and used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to groupon and sum.
Delegating collectors are passed a reference to the ResponseBuilder and can
place maps with analytic output directory into the SolrQueryResponse with the
add() method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl., where id is
specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different topdocs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With delegating collectors, you'll need to override the merge method to merge
the analytic output from the shards. An example of how this works is provided
in the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the aggregator.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.delegating={!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27}sum&cl.delegating={!+id=%272%27+groupby=%27manu_id_s%27%20column=%27weight%27}sum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable doclist Sorting with Topdocs Collectors*
You can specify two types of pluggable collectors. The first type is the
topdocs collector. For example:
cl.topdocs=
The above param points to the named collectorFactory in the solrconfig.xml to
construct the collector. Topdocs collectorFactorys must return collectors that
extend the TopDocsCollector base class. Topdocs collectors are responsible for
collecting the doclist.
You can pass parameters to the topdocs collector using local params syntax. For
example:
cl.topdocs={! sort=mycustomesort}mycollector
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of delegating collectors with the
"cl.delegating" parameter. Delegating collectors are designed to collect
something else besides the doclist. Typically this would be some type of custom
analytic.
cl.delegating=sum
The parameter above specifies a delegating collector named sum. Like the
topdocs collectors, "sum" points to the named collectorFactories in the
solrconfig.xml. You can specificy more delegating collectors by adding
additional cl.delegating parameters.
Delegating collector factories must return Collector instances that extend
DelegatingCollector.
A sample delegating collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to the delegating collectors with solr local param
syntax.
For example:
"cl.delegating={! id=1 groupby=field1 column=field2}sum"
The "id" parameter is mandatory for delegating collectors and used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to groupon and sum.
Delegating collectors are passed a reference to the ResponseBuilder and can
place maps with analytic output directory into the SolrQueryResponse with the
add() method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl., where id is
specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different topdocs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With delegating collectors, you'll need to override the merge method to merge
the analytic output from the shards. An example of how this works is provided
in the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the aggregator.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.delegating={!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27}sum&cl.delegating={!+id=%272%27+groupby=%27manu_id_s%27%20column=%27weight%27}sum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler
[jira] [Updated] (SOLR-4465) Configurable Collectors
[
https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4465:
-
Description:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.component.CollectorFactory, which implements logic that
returns the default TopScoreDocCollector and TopFieldCollector.
To create your own collectorFactory you must subclass the default
CollectorFactory and at a minimum override the getCollector method to return
your new collector.
The parameter "cl" turns on pluggable collectors:
cl=true
If cl is not in the parameters, Solr will automatically use the default
collectorFactory.
*Pluggable doclist Sorting with Topdocs Collectors*
You can specify two types of pluggable collectors. The first type is the
topdocs collector. For example:
cl.topdocs=
The above param points to the named collectorFactory in the solrconfig.xml to
construct the collector. Topdocs collectorFactorys must return collectors that
extend the TopDocsCollector base class. Topdocs collectors are responsible for
collecting the doclist.
You can pass parameters to the topdocs collector using local params syntax. For
example:
cl.topdocs={! sort=mycustomesort}mycollector
*Pluggable Custom Analytics With Delegating Collectors*
You can also specify any number of delegating collectors with the
"cl.delegating" parameter. Delegating collectors are designed to collect
something else besides the doclist. Typically this would be some type of custom
analytic.
cl.delegating=sum
The parameter above specifies a delegating collector named sum. Like the
topdocs collectors, "sum" points to the named collectorFactories in the
solrconfig.xml. You can specificy more delegating collectors by adding
additional cl.delegating parameters.
Delegating collector factories must return Collector instances that extend
DelegatingCollector.
A sample delegating collector is provided in the patch through the
org.apache.solr.handler.component.SumCollectorFactory.
This collectorFactory provides a very simple DelegatingCollector that groups by
a field and sums a column of floats. The sum collector is not designed to be a
fully functional sum function but to be a proof of concept for pluggable
analytics through delegating collectors.
You can send parameters to the delegating collectors with solr local param
syntax.
For example:
cl.delegating={! id=1 groupby=field1 column=field2}sum
The "id" parameter is mandatory for delegating collectors and used to identify
the output from the collector. In this example the "groupby" and "column"
params tell the sum collector which field to groupon and sum.
Delegating collectors are passed a reference to the ResponseBuilder and can
place maps with analytic output directory into the SolrQueryResponse with the
add() method.
Maps that are placed in the SolrQueryResponse are automatically added to the
outgoing response. The response will include a list named cl., where id is
specified in the local param.
*Distributed Search*
The CollectorFactory also has a method called merge(). This method aggregates
the results from each of the shards during distributed search. The "default"
CollectoryFactory implements the default merge logic for merging documents from
each shard. If you define a different topdocs collector you can override the
default merge method to merge documents in accordance with how they are
collected at the shard level.
With delegating collectors, you'll need to override the merge method to merge
the analytic output from the shards. An example of how this works is provided
in the SumCollectorFactory.
Each collectorFactory, that is specified in the http parameters, will have its
merge method applied by the aggregator.
*Testing the Patch With Sample Data*
1) Apply patch to Solr 4.1
2) Load sample data
3) Send the http command:
http://localhost:8983/solr/select?q=*:*&cl=true&facet=true&facet.field=manu_id_s&cl.delegating={!+id=%271%27+groupby=%27manu_id_s%27+column=%27price%27}sum&cl.delegating={!+id=%272%27+groupby=%27manu_id_s%27%20column=%27weight%27}sum
was:
This ticket provides a patch to add pluggable collectors to Solr. This patch
was generated and tested with Solr 4.1.
This is how the patch functions:
Collectors are plugged into Solr in the solconfig.xml using the new
collectorFactory element. For example:
The elements above define two collector factories. The first one is the
"default" collectorFactory. The class attribute points to
org.apache.solr.handler.c
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Switched to local param syntax for collectors. TODO: Update the description > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch > > > This ticket provides a patch to add pluggable collectors to Solr. This patch > was generated and tested with Solr 4.1. > This is how the patch functions: > Collectors are plugged into Solr in the solconfig.xml using the new > collectorFactory element. For example: > > > The elements above define two collector factories. The first one is the > "default" collectorFactory. The class attribute points to > org.apache.solr.handler.component.CollectorFactory, which implements logic > that returns the default TopScoreDocCollector and TopFieldCollector. > To create your own collectorFactory you must subclass the default > CollectorFactory and at a minimum override the getCollector method to return > your new collector. > You can tell Solr which collectorFactory to use at query time using http > parameters. All collector parameters start with the prefix "cl". > The parameter "cl" turns on pluggable collectors: > cl=true > If cl is not in the parameters, Solr will automatically use the default > collectorFactory. > *Pluggable doclist Sorting with Topdocs Collectors* > You can specify two types of pluggable collectors. The first type is the > topdocs collector. For example: > cl.topdocs= > The above param points to the named collectorFactory in the solrconfig.xml to > construct the collector. Topdocs collectorFactorys must return collectors > that extend the TopDocsCollector base class. Topdocs collectors are > responsible for collecting the doclist. > You can pass parameters to the topdocs collectors by adding "cl." http > parameters. By convention you can pass parameters to the topdocs collector > like this: > cl.topdocs.max=100 > This parameter will be added to the collector spec because of the "cl." > prefix and passed to the collectorFactory. > *Pluggable Custom Analytics With Delegating Collectors* > You can also specify any number of delegating collectors with the > "cl.delegating" parameter. Delegating collectors are designed to collect > something else besides the doclist. Typically this would be some type of > custom analytic. > cl.delegating=sum,ave > The parameter above specifies two delegating collectors named sum and ave. > Like the topdocs collectors these point to named collectorFactories in the > solrconfig.xml. > Delegating collector factories must return Collector instances that extend > DelegatingCollector. > A sample delegating collector is provided in the patch through the > org.apache.solr.handler.component.SumCollectorFactory. > This collectorFactory provides a very simple DelegatingCollector that groups > by a field and sums a column of floats. The sum collector is not designed to > be a fully functional sum function but to be a proof of concept for pluggable > analytics through delegating collectors. > To communicate with delegating collectors you need to reference the name and > ordinal of the collector. > The ordinal refers to the collectors ordinal in the comma separated list. > For example: > cl.delegating=sum,ave&cl.sum.0.groupby=field1 > The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to > group by "field1". > Delegating collectors are passed a reference to the ResponseBuilder and can > place maps with analytic output directory into the SolrQueryResponse with the > add() method. > Maps that are placed in the SolrQueryResponse are automatically added to the > outgoing response. > *Distributed Search* > The CollectorFactory also has a method called merge(). This method aggregates > the results from each of the shards during distributed search. The "default" > CollectoryFactory implements the default merge logic for merging documents > from each shard. If you define a different topdocs collector you can override > the default merge method to merge documents in accordance with how they are > collected at the shard level. > With delegating collectors, you'll need to override the merge method to merge > the analytic output from the shards. An example of how th
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You can tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl". The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type of custom analytic. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you can override the default merge method to merge documents in accordance with how they are collected at the shard level. With delegating collectors, you'll need to override the merge method to merge the analytic output from the shards. An example of how this works is provided in the SumCollectorFactory. Each collectorFactory, that is specified in the http parameters, will have its merge method applied by the aggregator. *Testing the Patch With Sample Data* 1) Apply patch to Solr 4.1 2) Load sample data 3) Send the http command: http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true&cl=true&cl.topdocs=default&cl.delegating=sum&cl.sum.0.groupby=manu_id_s&cl.sum.0.column=price The doclist will be generated by the "default" topdocs collector and the output will include a map named "cl.sum.0" which will have output from the delegating sum collector. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using t
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This ticket provides a patch to add pluggable collectors to Solr. This patch > was generated and tested with Solr 4.1. > This is how the patch functions: > Collectors are plugged into Solr in the solconfig.xml using the new > collectorFactory element. For example: > > > The elements above define two collector factories. The first one is the > "default" collectorFactory. The class attribute points to > org.apache.solr.handler.component.CollectorFactory, which implements logic > that returns the default TopScoreDocCollector and TopFieldCollector. > To create your own collectorFactory you must subclass the default > CollectorFactory and at a minimum override the getCollector method to return > your new collector. > You can tell Solr which collectorFactory to use at query time using http > parameters. All collector parameters start with the prefix "cl". > The parameter "cl" turns on pluggable collectors: > cl=true > If cl is not in the parameters, Solr will automatically use the default > collectorFactory. > *Pluggable doclist Sorting with Topdocs Collectors* > You can specify two types of pluggable collectors. The first type is the > topdocs collector. For example: > cl.topdocs= > The above param points to the named collectorFactory in the solrconfig.xml to > construct the collector. Topdocs collectorFactorys must return collectors > that extend the TopDocsCollector base class. Topdocs collectors are > responsible for collecting the doclist. > You can pass parameters to the topdocs collectors by adding "cl." http > parameters. By convention you can pass parameters to the topdocs collector > like this: > cl.topdocs.max=100 > This parameter will be added to the collector spec because of the "cl." > prefix and passed to the collectorFactory. > *Pluggable Custom Analytics With Delegating Collectors* > You can also specify any number of delegating collectors with the > "cl.delegating" parameter. Delegating collectors are designed to collect > something else besides the doclist. Typically this would be some type of > custom analytic. > cl.delegating=sum,ave > The parameter above specifies two delegating collectors named sum and ave. > Like the topdocs collectors these point to named collectorFactories in the > solrconfig.xml. > Delegating collector factories must return Collector instances that extend > DelegatingCollector. > A sample delegating collector is provided in the patch through the > org.apache.solr.handler.component.SumCollectorFactory. > This collectorFactory provides a very simple DelegatingCollector that groups > by a field and sums a column of floats. The sum collector is not designed to > be a fully functional sum function but to be a proof of concept for pluggable > analytics through delegating collectors. > To communicate with delegating collectors you need to reference the name and > ordinal of the collector. > The ordinal refers to the collectors ordinal in the comma separated list. > For example: > cl.delegating=sum,ave&cl.sum.0.groupby=field1 > The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to > group by "field1". > Delegating collectors are passed a reference to the ResponseBuilder and can > place maps with analytic output directory into the SolrQueryResponse with the > add() method. > Maps that are placed in the SolrQueryResponse are automatically added to the > outgoing response. > *Distributed Search* > The CollectorFactory also has a method called merge(). This method aggregates > the results from each of the shards during distributed search. The "default" > CollectoryFactory implements the default merge logic for merging documents > from each shard. If you define a different topdocs collector you may need to > change the default merge method to merge documents in accordance with how > they are being collected at the shard level. > With delegating collectors, you'll need to overide the merge method to merge > the analytic outputs from the shards. An example of how this works is provide > in the SumCollectorFactory. > Each collectorFactory, that is specified in th
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: (was: SOLR-4465.patch) > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This ticket provides a patch to add pluggable collectors to Solr. This patch > was generated and tested with Solr 4.1. > This is how the patch functions: > Collectors are plugged into Solr in the solconfig.xml using the new > collectorFactory element. For example: > > > The elements above define two collector factories. The first one is the > "default" collectorFactory. The class attribute points to > org.apache.solr.handler.component.CollectorFactory, which implements logic > that returns the default TopScoreDocCollector and TopFieldCollector. > To create your own collectorFactory you must subclass the default > CollectorFactory and at a minimum override the getCollector method to return > your new collector. > You can tell Solr which collectorFactory to use at query time using http > parameters. All collector parameters start with the prefix "cl". > The parameter "cl" turns on pluggable collectors: > cl=true > If cl is not in the parameters, Solr will automatically use the default > collectorFactory. > *Pluggable doclist Sorting with Topdocs Collectors* > You can specify two types of pluggable collectors. The first type is the > topdocs collector. For example: > cl.topdocs= > The above param points to the named collectorFactory in the solrconfig.xml to > construct the collector. Topdocs collectorFactorys must return collectors > that extend the TopDocsCollector base class. Topdocs collectors are > responsible for collecting the doclist. > You can pass parameters to the topdocs collectors by adding "cl." http > parameters. By convention you can pass parameters to the topdocs collector > like this: > cl.topdocs.max=100 > This parameter will be added to the collector spec because of the "cl." > prefix and passed to the collectorFactory. > *Pluggable Custom Analytics With Delegating Collectors* > You can also specify any number of delegating collectors with the > "cl.delegating" parameter. Delegating collectors are designed to collect > something else besides the doclist. Typically this would be some type of > custom analytic. > cl.delegating=sum,ave > The parameter above specifies two delegating collectors named sum and ave. > Like the topdocs collectors these point to named collectorFactories in the > solrconfig.xml. > Delegating collector factories must return Collector instances that extend > DelegatingCollector. > A sample delegating collector is provided in the patch through the > org.apache.solr.handler.component.SumCollectorFactory. > This collectorFactory provides a very simple DelegatingCollector that groups > by a field and sums a column of floats. The sum collector is not designed to > be a fully functional sum function but to be a proof of concept for pluggable > analytics through delegating collectors. > To communicate with delegating collectors you need to reference the name and > ordinal of the collector. > The ordinal refers to the collectors ordinal in the comma separated list. > For example: > cl.delegating=sum,ave&cl.sum.0.groupby=field1 > The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to > group by "field1". > Delegating collectors are passed a reference to the ResponseBuilder and can > place maps with analytic output directory into the SolrQueryResponse with the > add() method. > Maps that are placed in the SolrQueryResponse are automatically added to the > outgoing response. > *Distributed Search* > The CollectorFactory also has a method called merge(). This method aggregates > the results from each of the shards during distributed search. The "default" > CollectoryFactory implements the default merge logic for merging documents > from each shard. If you define a different topdocs collector you may need to > change the default merge method to merge documents in accordance with how > they are being collected at the shard level. > With delegating collectors, you'll need to overide the merge method to merge > the analytic outputs from the shards. An example of how this works is provide > in the SumCollectorFactory. > Each collectorFactory, that is spec
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You can tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl". The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type of custom analytic. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. Each collectorFactory, that is specified in the http parameters, will have its merge method applied by the aggregator. *Testing the Patch With Sample Data* 1) Apply patch to Solr 4.1 2) Load sample data 3) Send the http command: http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true&cl=true&cl.topdocs=default&cl.delegating=sum&cl.sum.0.groupby=manu_id_s&cl.sum.0.column=price The doclist will be generated by the "default" topdocs collector and the output will include a map named "cl.sum.0" which will have output from the delegating sum collector. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You can tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl". The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type of custom analytic. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. *Testing the Patch With Sample Data* 1) Apply patch to Solr 4.1 2) Load sample data 3) Send the http command: http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true&cl=true&cl.topdocs=default&cl.delegating=sum&cl.sum.0.groupby=manu_id_s&cl.sum.0.column=price The doclist will be generated by the "default" topdocs collector and the output will include a map named "cl.sum.0" which will have output from the delegating sum collector. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The firs
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You can tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type of custom analytic. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. *Testing the Patch With Sample Data* 1) Apply patch to Solr 4.1 2) Load sample data 3) Send the http command: http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true&cl=true&cl.topdocs=default&cl.delegating=sum&cl.sum.0.groupby=manu_id_s&cl.sum.0.column=price The doclist will be generated by the "default" topdocs collector and the output will include a map named "cl.sum.0" which will have output from the delegating sum collector. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The fir
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You can tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance which is passed to CollectorFactories. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type of custom analytic. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. *Testing the Patch With Sample Data* 1) Apply patch to Solr 4.1 2) Load sample data 3) Send the http command: http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true&cl=true&cl.topdocs=default&cl.delegating=sum&cl.sum.0.groupby=manu_id_s&cl.sum.0.column=price The doclist will be generated by the "default" topdocs collector and the output will include a map named "cl.sum.0" which will have output from the delegating sum collector. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type of custom analytic. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. *Testing the Patch With Sample Data* 1) Apply patch to Solr 4.1 2) Load sample data 3) Send the http command: http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true&cl=true&cl.topdocs=default&cl.delegating=sum&cl.sum.0.groupby=manu_id_s&cl.sum.0.column=price The doclist will be generated by the "default" topdocs collector and the output will include a map named "cl.sum.0" which will have output from the delegating sum collector. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFac
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Pluggable doclist Sorting with Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Pluggable Custom Analytics With Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some type custom analytic output. cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. *Topdocs Collectors* You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. *Delegating Collectors* You can also specify any number of delegating collectors with the "cl.delegating" parameter: cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some kind of custom analytic. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. You can also specify any number of delegating collectors with the "cl.delegating" parameter: cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some kind of custom analytic. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. *Distributed Search* The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collecto
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. You can also specify any number of delegating collectors with the "cl.delegating" parameter: cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must return Collector instances that extend DelegatingCollector. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some kind of custom analytic. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. was: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Description: This ticket provides a patch to add pluggable collectors to Solr. This patch was generated and tested with Solr 4.1. This is how the patch functions: Collectors are plugged into Solr in the solconfig.xml using the new collectorFactory element. For example: The elements above define two collector factories. The first one is the "default" collectorFactory. The class attribute points to org.apache.solr.handler.component.CollectorFactory, which implements logic that returns the default TopScoreDocCollector and TopFieldCollector. To create your own collectorFactory you must subclass the default CollectorFactory and at a minimum override the getCollector method to return your new collector. You tell Solr which collectorFactory to use at query time using http parameters. All collector parameters start with the prefix "cl.". All parameters that start with "cl." are gathered up and added to a CollectorSpec instance. The parameter "cl" turns on pluggable collectors: cl=true If cl is not in the parameters, Solr will automatically use the default collectorFactory. You can specify two types of pluggable collectors. The first type is the topdocs collector. For example: cl.topdocs= The above param points to the named collectorFactory in the solrconfig.xml to construct the collector. Topdocs collectorFactorys must return collectors that extend the TopDocsCollector base class. Topdocs collectors are responsible for collecting the doclist. You can pass parameters to the topdocs collectors by adding "cl." http parameters. By convention you can pass parameters to the topdocs collector like this: cl.topdocs.max=100 This parameter will be added to the collector spec because of the "cl." prefix and passed to the collectorFactory. You can also specify any number of delegating collectors with the "cl.delegating" parameter: cl.delegating=sum,ave The parameter above specifies two delegating collectors named sum and ave. Like the topdocs collectors these point to named collectorFactories in the solrconfig.xml. Delegating collector factories must extend DelegatingCollector. Delegating collectors are designed to collect something else besides the doclist. Typically this would be some kind of custom analytic. A sample delegating collector is provided in the patch through the org.apache.solr.handler.component.SumCollectorFactory. This collectorFactory provides a very simple DelegatingCollector that groups by a field and sums a column of floats. The sum collector is not designed to be a fully functional sum function but to be a proof of concept for pluggable analytics through delegating collectors. To communicate with delegating collectors you need to reference the name and ordinal of the collector. The ordinal refers to the collectors ordinal in the comma separated list. For example: cl.delegating=sum,ave&cl.sum.0.groupby=field1 The "cl.sum.0.groupy" parameter tells the "sum" collector at the 0 ordinal to group by "field1". Delegating collectors are passed a reference to the ResponseBuilder and can place maps with analytic output directory into the SolrQueryResponse with the add() method. Maps that are placed in the SolrQueryResponse are automatically added to the outgoing response. The CollectorFactory also has a method called merge(). This method aggregates the results from each of the shards during distributed search. The "default" CollectoryFactory implements the default merge logic for merging documents from each shard. If you define a different topdocs collector you may need to change the default merge method to merge documents in accordance with how they are being collected at the shard level. With delegating collectors, you'll need to overide the merge method to merge the analytic outputs from the shards. An example of how this works is provide in the SumCollectorFactory. was: This issue is to add configurable custom collectors to Solr. This expands the design and work done in issue SOLR-1680 to include: 1) CollectorFactory configuration in solconfig.xml 2) Http parameters to allow clients to dynamically select a CollectorFactory and construct a custom Collector. 3) Make aspects of QueryComponent pluggable so that the output from distributed search can conform with custom collectors at the shard level. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Changed the CollectorSpec to hold a string->object map. Greg, hopefully this will help bring it in line with the grouping needs. The CollectorSpec is used to pass parameters at query time to the collectors. Also formalized the parameter passing to delegating collectors. Now you use both the name and the ordinal in the parameter. For example: cl.delegating=sum&cl.sum.0.column=price This tells the "sum" collector at ordinal 0 to sum the column "price". Will update the description of this ticket to have a detailed description of how pluggable collectors work. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added the merge() method to the SumCollectorFactory. This adds the distributed support for the proof of concept fot pluggable analytics using delegating collectors. Also changed the parameter spec to use ordinals to send parameters to the correct collector. For example if three delegating collectors are specified as: cl.delegating=sum,ave,min The ordinals for the three collectors would be 0,1,2. To pass parameters to sum collector factory you include the ordinal after the "cl". For example: cl.0.groupby=manu Tells the collector at ordinal 0 (sum) to groupby the manu field. Also changed caching logic so that if delegating collectors are used QueryResultCaching is turned off. TODO: Test, Test cases. Update the Description of this ticket to include full specification. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added a very simple delegating collector through the class SumCollectorFactory. This is a proof of concept for pluggable analytics using delegating collectors. This patch was created from the Solr 4.1 tag. To test it, apply the patch to Solr 4.1, load the sample data and issue the following query http://localhost:8983/solr/collection1/select?q=*:*&wt=xml&indent=true&cl=on&cl.topdocs=default&cl.delegating=sum&cl.sum.groupby=manu_id_s&cl.sum.column=price Your output will include a lst called sum which contains the output for grouping on the manu_id_s field and summing the price field. TODO: The distributed support for this still needs to be added. Collector parameters need to support Solr local params syntax. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added support for delegating collectors. This design allows for a "topdocs" collector to be wrapped by "delegating" collectors. The "topdocs" collector collects the doclist and docset. The delegating collectors are designed to collect aggregate data of some kind. The delegating collectors have access to the ResponseBuilder and through that can add Maps directly to the SolrQueryResponse. Both the topdocs collector and the delegating collectors take part in the merge of distributed results from shards. This paves the way for pluggable distributed analytics to be included with searches results. TODO: I believe Maps that are placed in the SolrQueryResponse are automatically output but some work needs to be done get them read in the solrj QueryResponse class so they can be merged. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.3 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch QueryResultKey now uses the CollectorSpec to compute hashCode() and equals(). This still needs lots of testing, but collectorFactories now play nicely with caching. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: (was: SOLR-4465.patch) > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch New patch with a couple of additions: 1) Added coded during initialization of the collectorFactories to handle condition where default collectorFactory is not defined in solrconfig. This makes this patch backwords compatible with 4.* solrconfigs. Tests now run with out null pointers. 2) Added the CollectorSpec class to hold the collector http parameters. This class will implement hashCode and equals and will be added to QueryResultKey. The QueryResultKey implementation of this is not in this patch so more work still needs be done on getting this cache ready. I have tested this patch with the default collector factory with sorting and ranking queries and in distributed mode. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch New patch that gives the QueryCommand a reference to the ResponseBuilder. The QueryCommand is passed to the CollectorFactory so custom collectors now have direct access to the ResponseBuilder and can add objects directly to the response. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Code reformatted to Lucene style. Seems to look good in intellij and vi. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch This patch moves QueryComponent.mergeIds to the CollectorFactory. This allows the CollectorFactory to control both the shard level collection of results and the merging of distributed results. The CollectorFactory was also moved from org.apache.solr.core in previous patches to org.apache.solr.handler.component. This patch is a full (untested) configurable collector implementation at the shard level and at the distributed search level. Testing and test cases will follow. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Refactored SolrIndexSearcher.getDocListNC and SolrIndexSearch.getDocListAndSet to clean up Collector creation. The CollectorFactory now has default logic for choosing between TopScoreDocCollector and TopFieldCollector. This patch is a full (untested) implementation of configurable collectors at the shard level. Design description to follow. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added custom collectors to: SolrIndexSearcher.getDocListNC, SolrIndexSearcher.getDocListAndSetNC > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added custom collectors to: SolrIndexSearcher.getDocListNC, SolrIndexSearcher.getDocListAndSetNC > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: (was: SOLR-4465.patch) > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Gathering up the collector http parameters and setting the collectorSpec on the QueryCommand. Ready for use in the SolrIndexSearcher. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added CollectorParams.java to hold the http collector parameters. Using the prefix "cl" collector parameters. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch Added CollectorFactory.java to patch > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4465: - Attachment: SOLR-4465.patch First patch which adds the code to read the collectorFactory element from the solrconfig.xml. This will be iterated to add more detail. > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
