Skip to content

Conversation

@jpountz
Copy link
Contributor

@jpountz jpountz commented Sep 1, 2015

From a user perspective, the main benefit from this upgrade is that the new
Lucene53Codec has disk-based norms. The elasticsearch directory has been fixed
to load these norms through mmap instead of nio.

Other changes include the removal of max_thread_states, the fact that
PhraseQuery and BooleanQuery are now immutable, and that deleted docs are now
applied on top of the Scorer API.

This change introduces a couple of AwaitsFixs but I don't think it should
hold us from merging.

From a user perspective, the main benefit from this upgrade is that the new
Lucene53Codec has disk-based norms. The elasticsearch directory has been fixed
to load these norms through mmap instead of nio.

Other changes include the removal of `max_thread_states`, the fact that
PhraseQuery and BooleanQuery are now immutable, and that deleted docs are now
applied on top of the Scorer API.

This change introduces a couple of `AwaitsFix`s but I don't think it should
hold us from merging.
@rmuir
Copy link
Contributor

rmuir commented Sep 1, 2015

looks great, +1

@dpursehouse
Copy link
Contributor

👍 I just did this change myself locally but you beat me to it.

jpountz added a commit that referenced this pull request Sep 1, 2015
@jpountz jpountz merged commit 7bc1acf into elastic:master Sep 1, 2015
@clintongormley clintongormley added :Core/Infra/Core Core issues without another label >upgrade and removed >enhancement labels Sep 1, 2015
@jpountz jpountz deleted the upgrade/lucene-5.3.0 branch September 1, 2015 14:09
@dpursehouse
Copy link
Contributor

Is there any possibility to include this in the 2.0.0 release?

@jpountz
Copy link
Contributor Author

jpountz commented Sep 25, 2015

@dpursehouse We are in the process of stabilizing 2.0 and this is a big change, so it won't be backported. The good news however is that we aim at releasing 2.1 relatively soon after 2.0.

jpountz added a commit to jpountz/elasticsearch that referenced this pull request Dec 17, 2015
This is a bug that I introduced in elastic#13239 while thinking that the differences
were due to changes in Lucene: extractUnknownQuery is also called when span
extraction already succeeded, so we should only fall back to Weight.extractTerms
if no spans have been extracted yet.

Close elastic#15291
jpountz added a commit that referenced this pull request Dec 17, 2015
This is a bug that I introduced in #13239 while thinking that the differences
were due to changes in Lucene: extractUnknownQuery is also called when span
extraction already succeeded, so we should only fall back to Weight.extractTerms
if no spans have been extracted yet.

Close #15291
jpountz added a commit that referenced this pull request Dec 17, 2015
This is a bug that I introduced in #13239 while thinking that the differences
were due to changes in Lucene: extractUnknownQuery is also called when span
extraction already succeeded, so we should only fall back to Weight.extractTerms
if no spans have been extracted yet.

Close #15291
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Core/Infra/Core Core issues without another label >upgrade v2.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants