Sorting in Discover not working

Hi,

I am struggling to a seeming humble issue. I am not able to get the sorting by fields work on the 'Discover'.
So, in Discover, I 'added' a few fields to view and tried clicking on sort up/down arrows. The sorting is not working for any field except for the 'time' field. I tried this on String and also numeric fields. I also noticed, that for some fields the sort 'up/down' arrows do not show up.
I am wondering if enabling sorting and getting it to work expectedly needs some specific changes somewhere - may be mappings file or elsewhere. I am not sure.

I read the docs and did not come across any particulars for any additional configurations. Seems like it should work easily and by default.
I am using 7.4.0.

Any help will be highly appreciated.

1 Like

Hello,

yeah this is a bit confusing. So when you sort on timestamp - that is your primary sort and the other secondary sorts depend on it.

@Bargs can you please grab this one?

Thanks,
Bhavya

As Bhavya mentioned you might be getting tricked by the way multi-sort works. You can sort on multiple fields in Discover now. The first one you click on (or the one that is already selected in timestamp's case) will be your primary sort. The next one you click on will be your secondary sort. If you don't want to sort on timestamp, just click the arrow in the timestamp column again to remove that sort. There are tooltips on the arrow buttons to help you understand what each click will do.

About the fields without sort buttons: these are probably not sortable due to how they're mapped. text fields are not sortable by default. If you have a keyword version of that text field then you can sort on that. The keyword fields usually don't show up by default in the sidebar because they're typically multi fields that don't exist in the source document. You can make them visible in the sidebar (so they can be added as columns) by opening the settings in the sidebar and unchecking "Hide missing fields".

Hi @Bargs, @bhavyarm, thanks a ton. Thats exactly what was tricking me. Also, I find the information about using multi-fields in Discover and for sort also very useful.
This sorts me out. Thanks guys!

Edit: I am also using scripted fields because I need pretty names for my fields. Your responses got the sorting to work for all fields - scripted, normal and also multi-fields. However, now there is another issue I am facing. In the discover table data, I can hover over any cell and click on it to add a filter. This filter works when the field is normal, but if its a scripted field, the filter does not work. Any idea?

If you only need nice display names, have you tried using a field formatter? These can be more lightweight performance-wise because the formatting is done in the browser rather than in Elasticsearch. Search will be more performant if done against regular fields vs a script.

If a field formatter won't do the job for you, could you open up your browser's dev tools and see if there's an error when filtering on the scripted field? Filter on scripted fields should work, so there must be something funny going on.

@Bargs, I looked into field formatter. I want to format the field 'names' not 'values', so I think it won't help me.
I raised another topic for the filtering here - How to 'filter' in Discover when the field is a scripted field. @Larry_Gregory tells me its a known limitation.
Now, I am thinking of alternate solutions.
The only reason I had to use scripted fields was prettier names for the fields. The script only contained reassignment of the same value to another field with a prettier name.
I would like to try Aliases or ditch the prettier names altogether.

Field aliases would be an ideal solution, but unfortunately Kibana does not support them well at the moment https://github.com/elastic/kibana/issues/21705

Personally, if ditching the pretty names for the time being is an option, I would do that instead of creating scripted fields just for that purpose. Scripted fields will have a major impact on performance when used in filtering and aggregations so it is a big cost to pay for having nicer field names.

Right, we will ditch pretty field names until Kibana supports it..

Hi @Bargs @bhavyarm,

I am back with another doubt.
I have ditched the 'pretty labels' in discover table. We are using discover table for showing documents, sorting on columns and filtering on fields. In order for sorting to work on for 'text' columns, I have to use the .keyword variant of the field. I could easily added the .keyword variants to discover table, however, they do not show a value. They are all empty. I cross-checked by adding the .text variant and the column has data. So, for same fields, the .keyword has no data while the normal/main field has data.
This is getting at me. I was thinking of making the .keyword and main field and .text as multi-field. But, this will not fully solve my problem. I also have dynamic fields and for which Kibana creates the main field with .text analysis and multi-field with .keyword analysis. So, for multi-fields the issue will still continue.

Suggestions on how to get around with it?

Thanks..

Have you tried using dynamic templates in your index mappings? This should allow you to control how text fields are dynamically mapped.

Thanks. I tried that and it worked!. Phew.. that was a lot of work to just get the discover table working per expectations.

1 Like

Yeah, handling of multi fields is still not ideal by a long shot. There is a ticket in github for this issue https://github.com/elastic/kibana/issues/7419

It's possible this issue will get some traction soon, because we're now storing the field information we need in Kibana to understand the relationship between fields and their multi-fields, and the discover doc table will be getting some love soon.

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.