lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uri Boness (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-236) Field collapsing
Date Fri, 18 Dec 2009 22:50:18 GMT

    [ 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.


Mime
View raw message