On Thu, Jun 11, 2009 at 9:20 AM, Uwe Schindler<u...@thetaphi.de> wrote:
> In my opinion, solr and lucene should exchange technology much more. Solr > should concentrate on the "search server" and lucene should provide the > technology. +1 > All additional implementations inside solr like faceting and so > on, could also live in lucene. I would have nice usages for it (I do not use > Solr, but have my own Lucene framework, that I cannot give up because of > various reasons). But e.g. Solr's facetting, Solr's analyzers and so on > would be great in lucene as "modules". +1 > I get a lot of questions all the > time, how to do this and that, because the people don't understand, why they > must first map the float to an int. If they do it, the next question is: > "why does this work, I do not want to loose precision" and so on. I will do > it with TrieTokenStream Exactly! Those are new users struggling with trie... Lucene's consumability is important. > In my opinion, the classes should stay Trie* and not Numeric*. Maybe we have > different implementations for numeric Range queries in future. In this case, > I think Yonik is right. The class name should describe how it works if there > may be different and incompatible implementations in future. But... we don't name our other classes according to how they're implemented? EG, JavaCCQueryParser or JFlexQueryParser, or writeSingleDocSegmentInRAM (instead of addDocument, pre-2.3), or bufferPendingDelete (instead of deleteDocument), or RangeQueryAsBooleanQuery, RangeQueryAsConstantScoreFilter, SortUsingFieldCache, etc. I absolutely love "trie", as a developer, but the average user won't know what the trie data structure is. TrieRangeQuery is less consumable than NumericRangeQuery (or, simply RangeQuery). As a user I know Lucene is doing all kinds of cool stuff under the hood to get its job done... but those cool things shouldn't be in the names. The name should describe what it does, not how... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
