On Wed, Jun 10, 2009 at 6:07 PM, Yonik Seeley<yo...@lucidimagination.com> wrote:
> Really goes into Solr land... my pref for Lucene is to remain a core > expert-level full-text search library and keep out things that are > easy to do in an application or at another level. I think this must be the crux of our disagreement. I feel, instead, that Lucene should stand on its own, as a useful search library, with a consumable API, good defaults, etc. Lucene is more than "the expert level search API that's embedded in Solr". Lucene is consumed directly by apps other than Solr. In fact, I think there are many things in Solr that naturally belong in Lucene (and over time we've been gradually slurping them down). The line/criteria has always been rather blurry... In Lucene, we should be able to add a NumericField to a document, index it, and then create RangeFilter or Sort on that field and have things "just work". Unfortunately, we are far from being able to do so today. We can (and should, for 2.9) make baby steps towards this, by aborbing trie* into core, but you're still gonna have to "just know" to make the specific FieldCache parser and specific NumericRangeQuery to match how you indexed. It's awkward and not consumable, but I think it'll just have to do for now... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
