[
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792686#action_12792686
]
Uri Boness commented on SOLR-236:
---------------------------------
Essentially it boils down to two options:
# Keep it out of the trunk, in which case users that will need this
functionality will only get it by working with a patched Solr version of their
own, or use a branch (in both cases, most likely they will miss the continuous
work done on the trunk unless they keep on merging the changes)
# Keep in the trunk with some caveats, in which case they users have a chance
to use this functionality out of the box
In both cases, the user have a choice to make:
- be satisfied by the performance of this feature
- look for an alternative solution (other products)
- give up this functionality all together (if their business requirements allow
that)
So the main difference here I would say is in how easy you'd like to provide
this functionality to the users. On the Solr development part, indeed once this
is committed to the trunk there's much more responsibility on the committers to
make it work (enhance performance and fix bugs)... but this is a *good* thing
as there is a high demand for this feature and as a community driven project
this demand should to be satisfied. And I *do* think that the number of users
using this patch already is a good indicator that it is good enough for quite a
lot of use cases.
I do agree though that before committing anything, the public API should be
re-evaluated to minimize chances for BWC issues later on. BTW, regarding the
response, Solr already has a few places where the response format is still
marked as experimental and as subject to changes in the future (but it doesn't
stop people from using this functionality as they take the responsibility to
adapt to any such future changes when the come).
Now... writing this, it suddenly occurred to me that there might be another
solution to this all discussion which is in a way a combination of many of the
suggestions in this thread. What if, this patch would be split to two: the
changes to the core and the component itself. Now, if the changes to the core
are not that drastic and make sense (or at least everyone can live with them)
then perhaps they can be committed to the trunk. As for the rest of the patch
(which consists of the search components and its other supporting classes),
this can be put in SVN as separate branch for contrib. The good thing about
this solution is that the work done on this functionality will be in SVN so you
benefit from it as David mentioned above. The other benefit is that with this
layout you can actually build the branched code base separately and distribute
this functionality as a separate jar which can be deployed in Solr 1.5x
distribution. Again, a bit of work left to the users (too much to my taste) but
at least they're not forced to use a patched version of Solr. Would that be a
possible solution?
> Field collapsing
> ----------------
>
> Key: SOLR-236
> URL: https://issues.apache.org/jira/browse/SOLR-236
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Emmanuel Keller
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.5
>
> Attachments: collapsing-patch-to-1.3.0-dieter.patch,
> collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch,
> collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-3.patch,
> field-collapse-4-with-solrj.patch, field-collapse-5.patch,
> field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch,
> field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch,
> field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch,
> field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch,
> field-collapse-5.patch, field-collapse-5.patch,
> field-collapse-solr-236-2.patch, field-collapse-solr-236.patch,
> field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch,
> field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff,
> field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff,
> quasidistributed.additional.patch, SOLR-236-FieldCollapsing.patch,
> SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch,
> SOLR-236.patch, SOLR-236.patch, SOLR-236.patch, solr-236.patch,
> SOLR-236_collapsing.patch, SOLR-236_collapsing.patch
>
>
> This patch include a new feature called "Field collapsing".
> "Used in order to collapse a group of results with similar value for a given
> field to a single entry in the result set. Site collapsing is a special case
> of this, where all results for a given web site is collapsed into one or two
> entries in the result set, typically with an associated "more documents from
> this site" link. See also Duplicate detection."
> http://www.fastsearch.com/glossary.aspx?m=48&amid=299
> The implementation add 3 new query parameters (SolrParams):
> "collapse.field" to choose the field used to group results
> "collapse.type" normal (default value) or adjacent
> "collapse.max" to select how many continuous results are allowed before
> collapsing
> TODO (in progress):
> - More documentation (on source code)
> - Test cases
> Two patches:
> - "field_collapsing.patch" for current development version
> - "field_collapsing_1.1.0.patch" for Solr-1.1.0
> P.S.: Feedback and misspelling correction are welcome ;-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
