On Thu, Oct 27, 2016 at 2:45 PM, Yonik Seeley <[email protected]> wrote: > On Thu, Oct 27, 2016 at 5:10 AM, Adrien Grand <[email protected]> wrote: >> [...] the discrepancy between the best practices as recommended by Lucene > > Different discrepancies have different reasons... one shouldn't > attempt to paint them all with the same brush. > - For some issues, it may simply be a lack of volunteers (see "Why > Solr doesn't use Point fields" below). > - For some issues, there may not actually be consensus (and I've been > a Lucene committer before Solr even saw the light of day, so hopefully > my opinions would be included in the "recommended by Lucene".
Yes, you have near infinite Apache Lucene/Solr merit, Yonik, but for the past several years your interactions with Lucene have largely been obstructionist vs. helping to improve things. Your comments on https://issues.apache.org/jira/browse/LUCENE-7407 is a fresh example. Your comments on https://issues.apache.org/jira/browse/LUCENE-7521, triggering Adrien sending this email, is another fresh example. Your threat to veto the original addition of Uwe's NumericFields to Lucene's core stands out in my (long) memory as another. Being against volunteers offering to improve Solr's javadocs a few years ago stands out as yet another. > - For some issues, there may be consensus to "recommend X", but that > doesn't imply a consensus to prohibit all alternatives. Software moves forward and we cannot continue to support poor past decisions like FieldCache just because a few users may prefer it. Carrying forward such ancient legacy code forever has a non-trivial cost to future development. When would you ever remove something? > With respect to "using doc values", I think most agree on that default > recommendation. That doesn't necessarily follow that everyone agrees > that FieldCache should be prohibited or should go away entirely. Yonik, if you really feel so strongly that Solr users should still have a FieldCache option (I strongly disagree) then why don't you step up?: Go help Adrien today, on https://issues.apache.org/jira/browse/LUCENE-7521? Put a patch up that moves the over-specialized packedints code, no longer useful to Lucene but apparently required by Solr's FieldCache, in your opinion, over to Solr's sources? Failing that, I think Lucene should just move on: Adrien's patch there really is a good step forward. > The fact that it was removed from Lucene so quietly under a JIRA > originally entitled "Move SlowCompositeReaderWrapper to solr sources" > (LUCENE-7283) was definitely surprising to many. There have been many references to FieldCache going away over the years, on various Jira issues, on the dev list, etc., so for you to claim it's a "surprise to many" is ridiculous: such "many" must not really follow Lucene's development and therefore should not feign surprise. > Why Solr doesn't use Point fields for numerics (yet): > > Some of the same Lucene/Solr committers that worked on Points in > Lucene also added support in Elasticsearch as well as "Lucene Server" > ( https://github.com/mikemccand/luceneserver ) > One might as well complain that it took until 2016 for Lucene to get > proper numeric index support. > This is volunteer development, and Tomas has been the only person to > find time to work on Points support. That's fine: it's an open source project, though I do think Solr's gradual demise has only been accelerated by you aggressively fighting for preserving all "old" ways of doing things. Solr hasn't even fully adopted near-real-time search yet. Such an attitude ("nothing can ever be removed because a few users may want it") only makes it harder for volunteers like Tomas to e.g. add dimensional points support to Solr. But again, why not step up and help Tomas out? Take his latest patch/branch and iterate some, getting it closer to a committable state? > Why doesn't Solr use SortedNumericDocValues (yet): > > Same as above. Some Lucene/Solr committers added support to > Elasticsearch and to luceneserver, but none have gotten around to > adding support to Solr yet. I don't think it's anyone's fault. No > one has argued against using SortedNumericDocValues (or Points for > that matter). But neither has anyone stepped up and contributed the > work. Right: it's nobody's fault, it's a volunteer effort. This is simply how open-source works. > Finally, Solr is not just an "example" of how to use Lucene. While > Lucene seems to rapidly change APIs every major release (and some back > incompatible changes are just because someone likes a name better), > Solr does not have that luxury. We have many users that depend on us, > and we've already made it hard enough for people to move, and too many > people are stuck back on v4.x. Sorry, but Solr has become a poor example of how to use Lucene at this point, in my opinion. I also think Elasticsearch is also a poor example, in other ways. These are exactly the reasons why I made the example "Lucene Server", to be as thin a wrapper around Lucene as possible, a good/simple example of how one could make a basic yet very functional single-node server on top of Lucene. Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
