Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <1759346823.1242169847417.JavaMail.jira@brutus>
Date: Tue, 12 May 2009 16:10:47 -0700 (PDT)
From: "Grant Ingersoll (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
In-Reply-To: <1089092633.1221505424636.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Grant Ingersoll commented on SOLR-773:
--------------------------------------

{quote}
1) What is the goal we want to achieve?

    * Provide a first iteration of a geographical search entity to SOLR
    * Bring an external popular plugin, in out of the cold into ASF and SOLR, helps solr users out, increases developers from 1 to many.
{quote}

Agreed on the first, not 100% certain on the second.  On the second, this issue is the gate keeper.  If people reviewing the patch feel there are better ways to do things, then we should work through them before committing.  What you are effectively seeing is an increase in the developers working on from 1 to many, it's just not on committed code.

{quote}
2) What is the level of commitment, and road map of spatial solutions in lucene and solr?

    * The primary goal of SOLR is as a text search engine, not GIS search, there are other and better ways to do that
      without reinventing the wheel and shoe horn-ing it into lucene.
      (e.g. persistent doc id mappings that can be referenced outside of lucene, so things like postGis and other tools can be used)
    * We can never fully solve everyone's needs at once, lets start with what we have, and iterate upon it.
    * I'm happy for any improvements as long as they keep to two goals A. don't make it stupid B. don't make it complex.
{quote}

On the first point, I don't follow.  Isn't LocalLucene and LocalSolr, just exactly a GIS search capability for Lucene/Solr?  I'm not sure if I would categorize it as shoe-horning.  There are many things that Lucene/Solr can power, GIS search is one of them.  By committing this patch (or some variation), we are saying Solr is going to support GIS search.  Of course, there are other ways to do it, but that doesn't preclude it from L/S.  The combination of text search plus GIS search is very powerful, as you know.  

Still, I think Yonik's main point is why reinvent the wheel when it comes to things like distributed search and the need for custom code for indexing, etc. when they likely can be handled through function queries and field types and therefore all of Solr's current functionality would just work.  The other capabilities (like sorting by a FunctionQuery) is icing on the cake that helps solve other problems as well.

Totally agree on the other points.  Also very cool to see the benchmarking info.


> Incorporate Local Lucene/Solr
> -----------------------------
>
>                 Key: SOLR-773
>                 URL: https://issues.apache.org/jira/browse/SOLR-773
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Grant Ingersoll
>            Assignee: Grant Ingersoll
>            Priority: Minor
>         Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, SOLR-773.patch, spatial-solr.tar.gz
>
>
> Local Lucene has been donated to the Lucene project.  It has some Solr components, but we should evaluate how best to incorporate it into Solr.
> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.