Highlighting field order not preserved in 1.2.1

All,

I noticed what I think is a regression in 1.2.1 from 0.90.9 where the order
of fields for highlighting is not preserved as it was in 0.90.9

For example, with a query where highlighting is defined such as

"highlight" : {
"require_field_match" : true,
"type" : "mycustomhighlighter",
"options" : {
"number_of_fragments" : 0,
"fragment_size" : 0
},
"fields" : {
"field1" : { },
"field2" : { },
"field3" : { },
"field4" : { },
"field5" : { },
"field6" : { }
}

In 0.90.9 the order in which fields would be highlighted would be field1,
field2, field3, field4, etc. In 1.2.1 it's arbitrary. I believe the cause
is the use of a HashMap vs using a LinkedHashMap in the constructor
of SearchContextHighlighter.java causing the insertion order to be lost.

The reason why I want order preserved is that I have a custom wrapping
highlighter to FVH that highlights only the first n fields (the ones most
likely to have hihglighting) and will only continue highlighting the
remaining fields (potentially hundreds) if no highlighting happened for the
initial set of fields. Doing this allows searches to execute very quickly
on average and only occasionally taking the hit of attempting to highlight
everything resulting in a 8-10x faster query on average.

All the best,

Bruce Ritchie

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

That'll be fixed in 1.3.0. I also needed the ordering to be consistent to
implement a similar trick to yours in the experimental highlighter.

Nik

On Wed, Jun 18, 2014 at 11:47 AM, Bruce Ritchie bruce.ritchie@gmail.com
wrote:

All,

I noticed what I think is a regression in 1.2.1 from 0.90.9 where the
order of fields for highlighting is not preserved as it was in 0.90.9

For example, with a query where highlighting is defined such as

"highlight" : {
"require_field_match" : true,
"type" : "mycustomhighlighter",
"options" : {
"number_of_fragments" : 0,
"fragment_size" : 0
},
"fields" : {
"field1" : { },
"field2" : { },
"field3" : { },
"field4" : { },
"field5" : { },
"field6" : { }
}

In 0.90.9 the order in which fields would be highlighted would be field1,
field2, field3, field4, etc. In 1.2.1 it's arbitrary. I believe the cause
is the use of a HashMap vs using a LinkedHashMap in the constructor
of SearchContextHighlighter.java causing the insertion order to be lost.

The reason why I want order preserved is that I have a custom wrapping
highlighter to FVH that highlights only the first n fields (the ones most
likely to have hihglighting) and will only continue highlighting the
remaining fields (potentially hundreds) if no highlighting happened for the
initial set of fields. Doing this allows searches to execute very quickly
on average and only occasionally taking the hit of attempting to highlight
everything resulting in a 8-10x faster query on average.

All the best,

Bruce Ritchie

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd30N2zFBfYqV%2BJkNWWCi7gEyx_xO2ntjZp2jVZBBzE1Ew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Thanks for the reply. I'll just have to checkout the 1.2.1 tag and patch it
myself till 1.3.0 is out.

Bruce

On Wednesday, June 18, 2014 11:58:21 AM UTC-4, Nikolas Everett wrote:

That'll be fixed in 1.3.0. I also needed the ordering to be consistent to
implement a similar trick to yours in the experimental highlighter.

Nik

On Wed, Jun 18, 2014 at 11:47 AM, Bruce Ritchie <bruce....@gmail.com
<javascript:>> wrote:

All,

I noticed what I think is a regression in 1.2.1 from 0.90.9 where the
order of fields for highlighting is not preserved as it was in 0.90.9

For example, with a query where highlighting is defined such as

"highlight" : {
"require_field_match" : true,
"type" : "mycustomhighlighter",
"options" : {
"number_of_fragments" : 0,
"fragment_size" : 0
},
"fields" : {
"field1" : { },
"field2" : { },
"field3" : { },
"field4" : { },
"field5" : { },
"field6" : { }
}

In 0.90.9 the order in which fields would be highlighted would be field1,
field2, field3, field4, etc. In 1.2.1 it's arbitrary. I believe the cause
is the use of a HashMap vs using a LinkedHashMap in the constructor
of SearchContextHighlighter.java causing the insertion order to be lost.

The reason why I want order preserved is that I have a custom wrapping
highlighter to FVH that highlights only the first n fields (the ones most
likely to have hihglighting) and will only continue highlighting the
remaining fields (potentially hundreds) if no highlighting happened for the
initial set of fields. Doing this allows searches to execute very quickly
on average and only occasionally taking the hit of attempting to highlight
everything resulting in a 8-10x faster query on average.

All the best,

Bruce Ritchie

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/4e219003-11c5-41bf-b465-88457cc97843%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.