On Sun, Mar 27, 2011 at 7:30 AM, Yonik Seeley <[email protected]>wrote:
> On Sat, Mar 26, 2011 at 2:17 PM, Ryan McKinley <[email protected]> wrote: > >>> > >>> No, the question is: what justification is there for adding spatial > >>> support to solr-only, leaving lucene with a broken contrib module, > >>> versus adding it where it belongs and exposing it to solr? > >> > >> There need not be any linkage to lucene to improve a Solr feature. > >> If you disagree, we should vote to clarify - this is too important > >> (and too much of a negative for Solr). > >> > > > > I don't think there is *requirement* to move the core spatial stuff to > > lucene, but I think there is huge benefit to both communities if > > things have as few dependencies as possible. To be frank, the spatial > > support in solr is pretty hairy -- it works for some use cases, but is > > not extendable and quite basic. Calling it 'distance' seems more > > appropriate then 'spatial' > > > Having something basic that works (and has a clean enough high level > HTTP interface) was clearly a win for Solr users. > > Of course a more fully featured spatial module would be a win for > everyone, but that's ignoring the more generic issue at hand here: > a patch that improves Solr's spatial > should not be blocked on the grounds that it does not improve Lucene's > spatial enough. > I don't think we need to see it that way, we want to improve both Solr and Lucene's spatial support, not block either. As you say, having a module is a win for everyone, Solr and Lucene alike, so it seems obvious that we should go down that path and the code in SOLR-2155 would make a great first addition. > > Likewise, the ridiculous notion that "Queries don't belong in Solr" > needs to be put to rest. Issues in and around this seem to be coming up a lot these days (I'm thinking FunctionQuerys too). Sounds like something that really does need to be openly discussed. > > -Yonik > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
