Should the default position_offset_gap be higher then 0? #7268
Labels
>enhancement
>feature
:Search/Mapping
Index mappings, including merging and defining field types
v2.0.0-beta2
Comments
|
++ |
|
Agreed. I don't know a ton about the internals, but I suspect the only possible low-level impact of increasing this by default is that we might overflow the vint used to store the offset, making the index slightly larger? If so, I'd think a modest gap of 10 should still be safe, right? |
clintongormley
added
:Search/Mapping
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this issue
Aug 24, 2015
This is much more fiddly than you'd expect it to be because of the way position_offset_gap is applied in StringFieldMapper. Instead of setting the default to 100 its simpler to make sure that all the analyzers default to 100 and that StringFieldMapper doesn't override the default unless the user specifies something different. Unless the index was created before 2.1, in which case the old default of 0 has to take. Also postition_offset_gaps less than 0 aren't allowed at all. New tests test that: 1. the new default doesn't match phrases across values with reasonably low slop (5) 2. the new default doest match phrases across values with reasonably high slop (50) 3. you can override the value and phrases work as you'd expect 4. if you leave the value undefined in the mapping and define it on a custom analyzer the the value from the custom analyzer shines through Closes elastic#7268
nik9000
added a commit
that referenced
this issue
Aug 25, 2015
This is much more fiddly than you'd expect it to be because of the way position_offset_gap is applied in StringFieldMapper. Instead of setting the default to 100 its simpler to make sure that all the analyzers default to 100 and that StringFieldMapper doesn't override the default unless the user specifies something different. Unless the index was created before 2.1, in which case the old default of 0 has to take. Also postition_offset_gaps less than 0 aren't allowed at all. New tests test that: 1. the new default doesn't match phrases across values with reasonably low slop (5) 2. the new default doest match phrases across values with reasonably high slop (50) 3. you can override the value and phrases work as you'd expect 4. if you leave the value undefined in the mapping and define it on a custom analyzer the the value from the custom analyzer shines through Closes #7268
|
Almost there - I've merged #12544 to 2.0 and master but I'll need another small tweak to master to make it compatible with the 2.0. I should have developed this against 2.0 and forward ported it to master. I did the opposite. But it'll be ok. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The default value of
position_offset_gapcan cause phrase matches across multiple field values. I think that is generally not what people want. Can it default to10or something?The text was updated successfully, but these errors were encountered: