lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shalin Shekhar Mangar <shalinman...@gmail.com>
Subject Re: Factor out a standalone, shared analysis package for Nutch/Solr/Lucene?
Date Sun, 28 Feb 2010 18:32:44 GMT
On Sun, Feb 28, 2010 at 9:37 PM, Ian Holsman <lists@holsman.net> wrote:

>
> waiting for SOLR developers to implement re-factorings and changes made to
> the core will hamper lucene development.
> and things like katta, elastic search, neo4j, and zoie will be treated like
> 2nd class citizens and suffer.
>

Lucene changes don't need to be in Solr immediately and they won't be, until
somebody has the itch. Many Lucene bugs have been caught by Solr's tests and
making sure that a change passes Solr's test suite is a good thing. A Lucene
change that fails Solr's tests is either a bug or a backwards-incompatible
API change. If it is the latter then I believe changing Solr is a good
lesson in the magnitude of changes needed in a typical Lucene application.
Possibly, those lessons can lead to a more flexible/simpler API. This is
relevant for new features as well. For example, look at how the trie range
query was affected when Solr came into the picture.

I know that many Lucene developers like to use newer features as soon as
possible. But seriously, how many update their Lucene applications to
support these changes in sync with a patch or even trunk? _*Striving*_ to
keep Solr in sync with Lucene will give instant feedback which, I think,
will help us build better APIs and give Lucene users a better experience.

Consider another argument: Solr's use of Lucene can be advertised as a
best-practice which can be a huge help for Lucene users. You want to know
how to add caching on top of Lucene? See Solr. Replication? See Solr etc.

As far as the other projects are concerned, I don't see why they will be
treated as 2nd class citizens. The Lucene core will continue to be separate
and if some of Solr's features are available to those projects in an easy to
assimilate Java API, they too benefit from it. It is a win-win situation.


> It will also hamper innovative new developments, as now 'oh.. this will
> break SOLR', or 'SOLR can't use that easily' will stop them. I'm curious how
> the NRT enhancements and payload changes would have gone if they had to wait
> for SOLR to change stuff to make them work. and most of the SOLR dev's are
> on the lucene dev list anyway.
>

Again, nobody is proposing that all new features must have corresponding
support in Solr. New features are anyway designed to be backward compatible
and all the proposal says is that the changes should not break Solr, which
makes sense.

-- 
Regards,
Shalin Shekhar Mangar.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message