atom feed19 messages in org.apache.lucene.solr-devRe: Lucene/Solr 7
FromSent OnAttachments
Adrien GrandJan 24, 2017 8:52 am 
Ishan ChattopadhyayaJan 24, 2017 9:16 am 
Joel BernsteinJan 24, 2017 9:28 am 
Michael McCandlessJan 24, 2017 9:43 am 
Joel BernsteinJan 24, 2017 10:02 am 
Tommaso TeofiliJan 24, 2017 10:09 am 
Michael McCandlessJan 24, 2017 11:01 am 
David SmileyJan 24, 2017 8:09 pm 
Uwe SchindlerJan 25, 2017 2:29 am 
Christine Poerschke (BLOOMBERG/ LONDON)Jan 25, 2017 2:38 am 
Ramkumar R. AiyengarJan 25, 2017 4:50 am 
Tomás Fernández LöbbeJan 25, 2017 9:36 am 
Anshum GuptaJan 25, 2017 1:21 pm 
Shawn HeiseyJan 26, 2017 11:51 am 
Ishan ChattopadhyayaJan 26, 2017 1:08 pm 
Adrien GrandJan 26, 2017 1:09 pm 
Adrien GrandJan 26, 2017 1:40 pm 
Shawn HeiseyJan 26, 2017 4:48 pm 
Tomás Fernández LöbbeJan 26, 2017 5:17 pm 
Subject:Re: Lucene/Solr 7
From:Ishan Chattopadhyaya (
Date:Jan 26, 2017 1:08:08 pm

My thinking was: We should backport PointFields work (SOLR-8396) right away and release a 6.5 with PointFields (as an additional field type). Perhaps in another month or two, if remaining work on PointFields is complete (the multi-valued support etc.), we should release a 6.6 with those changes and mark the TrieFields as deprecated and switching over to PointFields as default. Then, 7.0 onwards we could pull in the Legacy*Fields (that underlie the TrieFields) into the Solr codebase (and remove from Lucene) and continue to have TrieFields work. 8.0 onwards we can get rid of the TrieFields and the Legacy*Fields.

Does that sound reasonable and feasible?

On Fri, Jan 27, 2017 at 1:21 AM, Shawn Heisey <> wrote:

On 1/25/2017 10:36 AM, Tomás Fernández Löbbe wrote:

I think it would be great if we could use 7.0 to make point fields the default in Solr (i.e. change the example/default schemas to make "int", "long" etc use point fields implementation), but in order to do that, there are a number of point-related Jiras that need to be solved (MultiValued DV support to begin with, but there are other features that are still not working with points). I guess we can decide closer to the date, depending on how stable and feature complete they are.

The fast deprecation of the legacy numeric types has strong potential to impact a very large number of people who use older versions of *any* software based on Lucene, including Elasticsearch and Solr. If their current configuration uses the legacy types, they will be unable to upgrade to software using Lucene 7.0 and keep using their existing indexes.

If the legacy numeric types are removed from 7.0 in accordance with the way deprecation is usually handled, at least one minor Solr 6.x release should have point fields as the default numeric type before 7.0 gets released. Two or three releases would be better.

Because Solr does not yet have points support, we are already looking at a situation where all current Solr users upgrading to 7.0 are going to need to completely reindex. It will not be possible to keep using an existing index, regardless of the version.

I can think of two alternate ideas that would ease the pain even more: 1) Write a Lucene converter, similar to IndexUpgrader, or possibly *part* of IndexUpgrader in 6.x, that has the option of converting legacy numeric types to points. 2) Delay the removal of the legacy types until 8.0. Delaying would give users more time to migrate their configs and complete the necessary reindex before upgrading to a version that requires it. One of these alternate solutions would be as much a benefit to users of older Elasticsearch versions as it would be to Solr users.