lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Rowe (JIRA)" <>
Subject [jira] [Commented] (SOLR-2272) Join
Date Tue, 26 Apr 2011 18:17:04 GMT


Steven Rowe commented on SOLR-2272:

Mike M. wrote:
bq. for healthy Apache projects, where code can be freely refactored over time, it doesn't
matter much where the initial commit goes. Progress not perfection...


bq. But it has become evident, recently, that efforts to refactor Lucene/Solr sources to their
natural places are in fact strongly resisted

I think Simon nailed it on the head: [Lucene & Solr a one-way street?|].
 I find it difficult to defend this relationship, which was supposed to be symbiotic (benefitting
both Solr and Lucene), but which increasingly looks parasitic (i.e. most benefits accrue to
Solr, and most costs are borne by Lucene).

I agree with Mark: Robert's veto is political, in that it is based solely on a question of
policy.  I believe that Robert means to directly force re-examination of the Solr/Lucene merger,
and vetoing this issue is a means to that end.

Yonik wrote: 
bq. It's simply preposterous that an improvement to Solr be blocked because some might want
a lucene-usable module too.


But if this is true, then it *must* also be true that refactoring is possible, and not just
in theory.

> Join
> ----
>                 Key: SOLR-2272
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>         Attachments: SOLR-2272.patch, SOLR-2272.patch, SOLR-2272.patch
> Limited join functionality for Solr, mapping one set of IDs matching a query to another
set of IDs, based on the indexed tokens of the fields.
> Example:
> fq={!join  from=parent_ptr to:parent_id}child_doc:query

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message