On Wed, Mar 30, 2016 at 12:43 PM, Adrien Grand <[email protected]> wrote: > Hi Shawn, > > I think marking the legacy fields/queries as deprecated in Lucene in 6.0 is > the right thing to do in order to encourage users to migrate to the new > points API. If Solr needs to keep them around for 7.x, it would be fine to > move them to solr/ instead of lucene/ instead of a hard removal. Given that > it works on top of the postings API, it would not break.
Also see my issue (https://issues.apache.org/jira/browse/LUCENE-7075) where I proposed to at least get things headed to the backwards/ jar. And the uninverting issue is still being discussed. If you look at linked issues you will see the deprecated encoding is involved with the following modules: * core (not just field/query/utils classes, but stuff like precisionStep in the .document api!) * spatial (Deprecated GeoPoint encoding etc) * spatial-extras (Deprecated Bbox encoding etc) * misc (UninvertingReader) * queryparser (flexible and xml) * join The purpose of that issue is to make sure people have the stuff they need to move their code of the old encoding. I personally thought this would make the transition easier, and it was finding bugs/problems in points and improving the apis. I imagined it would just be me, but i created a ton of linked issues all up front just in case. I did not think anyone else would really be excited to work on these, because its not particularly exciting stuff, but thanks Nick, David, Martijn, etc who did. I didn't try to plan any grandiose schemes of *actually pulling the old encoding out* because this was plenty on its own. I tried to work on the fieldcache only because I was talking to Tomas and he mentioned it as a difficulty in cutting over solr. But I bailed after encountering complexity, and don't think it is the way to go, read the issue for my explanation. To me, this is why we have a backwards compatibility policy for N-1, it has to be a volunteer thing for some of this stuff: can't all be on Mike. I do personally think it is enough to release, "removing" or "moving" deprecations is something to worry about for master branch. I did mention in the issue an idea for a first step would be to get the core/ stuff pulled out somewhere better. Maybe the core/ stuff should go to the backwards-codec jar if we can detangle the deprecations from the .document api (e.g. maybe precisionStep can be a parameter on a tokenizer or analyzer or something, so its a little bit harder to use, but still works and not holding back core/'s .document api). But what to do about the other stuff? If i wanted to start removing deprecations now, I would be trying to just factor out the core/ NumericRangeQuery/NumericField stuff out to the backwards-codec jar. I hate modules depending on other ones, I really do, but just to iterate, I'd temporarily make all those other modules depend on backwards-codec/ jar and then remove deprecations from each one-by-one. Its too much to do all at once. I think we can do it this way iteratively without breaking solr. If solr wants to hang on to e.g. some spatial field with old numerics for an additional time (since it was still using it for 6.0), then the deprecated spatial field can be moved to solr. If not, lets nuke it. To me this seems the least controversial path, and its something that can be done iteratively. It has the downside of keeping "core" deprecated legacy numerics around for an extra major release in the backwards-codec jar. I think this "extra" back compat is ok in this case. Uwe made clean code :) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
