Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 26 Apr 2011 17:35:03 +0000 (UTC)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1706666235.3166.1303839303177.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <2930107.5921291769521301.JavaMail.jira@thor>
Subject: [jira] [Commented] (SOLR-2272) Join
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025342#comment-13025342 ] 

Michael McCandless commented on SOLR-2272:
------------------------------------------

bq. Now that you have thrown down the gauntlet, I do want to rise to the challenge, but I don't know what it is!

+1 this is hilarious :)  Nomatter what the gauntlet is, let's all rise to the occassion!

bq. Final location of code is not a good or valid reason to block commits IMO. That can be improved over time, when people back up there fricken wants with some code rather than road blocks. This is a political revert request - though I'm sure you will now try and twist it to some technical BS.

I generally agree with this, ie, 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...

But it has become evident, recently, that efforts to refactor
Lucene/Solr sources to their natural places are in fact strongly
resisted (eg, Yonik has now vetoed LUCENE-2995, which looked like a
great example of such a refactoring; LUCENE-2883 also met with
resistance).

Ie it now seems like we should try hard(er) to put new code in the
right place, up front, because we are in fact not really free to later
refactor it.

So... here's an idea: how about if someone volunteered to take Yonik's
latest patch here and make it a shared module, before committing?
Yonik (and everyone else), would you be OK with that?  (I'm not sure
anyone would volunteer now, but, it seems like this would be a way out
of this "impasse"...).


> Join
> ----
>
>                 Key: SOLR-2272
>                 URL: https://issues.apache.org/jira/browse/SOLR-2272
>             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: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org