# Highlighting field order not preserved in 1.2.1 **URL:** \ **Category:** Elasticsearch\ **Created:** [June 18, 2014, 3:47pm UTC](https://discuss.elastic.co/t/highlighting-field-order-not-preserved-in-1-2-1/18189 "2014-06-18T15:47:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Bruce\_Ritchie](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bruce_ritchie/32/9370_2.png) [@Bruce\_Ritchie](https://discuss.elastic.co/u/Bruce_Ritchie)\ **Post date:** [June 18, 2014, 3:47pm UTC](https://discuss.elastic.co/t/highlighting-field-order-not-preserved-in-1-2-1/18189/1 "2014-06-18T15:47:10Z")
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](mailto: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). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [June 18, 2014, 3:57pm UTC](https://discuss.elastic.co/t/highlighting-field-order-not-preserved-in-1-2-1/18189/2 "2014-06-18T15:57:50Z")
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](mailto: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](mailto: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) > [https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com?utm\_medium=email&utm\_source=footer](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](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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/CAPmjWd30N2zFBfYqV%2BJkNWWCi7gEyx_xO2ntjZp2jVZBBzE1Ew%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Bruce\_Ritchie](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bruce_ritchie/32/9370_2.png) [@Bruce\_Ritchie](https://discuss.elastic.co/u/Bruce_Ritchie)\ **Post date:** [June 18, 2014, 4:22pm UTC](https://discuss.elastic.co/t/highlighting-field-order-not-preserved-in-1-2-1/18189/3 "2014-06-18T16:22:18Z")
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](mailto:bruce....@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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@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) > > [https://groups.google.com/d/msgid/elasticsearch/919a7228-0cfe-42a6-a542-be8c83fbe044%40googlegroups.com?utm\_medium=email&utm\_source=footer](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](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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/4e219003-11c5-41bf-b465-88457cc97843%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:21am UTC](https://discuss.elastic.co/t/highlighting-field-order-not-preserved-in-1-2-1/18189/4 "2017-07-06T01:21:29Z")