lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-773) Incorporate Local Lucene/Solr
Date Tue, 12 May 2009 23:22:45 GMT

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

Grant Ingersoll edited comment on SOLR-773 at 5/12/09 4:21 PM:
---------------------------------------------------------------

{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 with text is one of them.  By committing
this patch (or some variation), we are saying Solr is going to support it.  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.


      was (Author: gsingers):
    {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.


Mime
View raw message