Sorting does not adhere to selected order after GWT 13.1 upgrade

[priyanka.barik]

We are observing an issue with sorting behavior after upgrading our application to GWT 13.1, specifically related to “Sort All Ascending/Descending” option. Sort All Ascending/Descending option, the displayed order does not consistently adhere to the selected sort across paginated results.
Observed Behavior-

• After analysis, we found that the GWT framework reapplies sorting each time a new page is loaded.
• If a single page contains loads with different Operational Status values, the order of those loads may appear to change within that page.
• The data set itself is correct — all expected loads are displayed.
• However, the sequence of records is locally re-adjusted per page, leading to an inconsistent ordering experience.

We would like to confirm:

1. Whether this is a known behavior or limitation with GWT 13.1 sorting + pagination.
2. If there is a recommended configuration or approach within Isomorphic/SmartGWT to enforce global sorting consistency across pages.
3. If any framework-level fix or workaround is available.

At this point, based on our investigation, we are unable to address this through application-level code changes and would appreciate your guidance.

Thank you for your support.

[Isomorphic]

Sorting is performed potentially on the client (in JavaScript) or the server (in SQL we generate, or in your app-level code). It's not clear which you're referring to, but nothing changed around sorting in 13.1.

Docs on how this works:
https://smartclient.com/smartgwtee-l...ResultSet.html

Live demo of sort switching from server to client, dynamically:
https://smartclient.com/smartgwtee/s...#adaptive_sort

What you may have noticed, which is not actually a change, is one of two things:

1. sort may shift as the cache is filled if your sort is not a total order

If your sort is not a "total order" (in the mathematics sense), then if you are sorted by an enum field with a lot of repeating values, there is no way for client and server sorting to match: the records with repeating values have the same sort cardinality, and which ones among that set come first is semi-random (often to do with which record was most recently updated, in SQL).

The only way to see this is to load the first page of a dataset and then scroll down until all pages are loaded, and even then, you normally won't see a shift because the client cache initially has the server's order.

If this ever matters, you can make your sort a total order by sorting by the PK, or some similar unique field, last.

2. server sort over shifts with unrelated changes

Same problem as above, but this you can see just at a SQL console, no web app or GWT at all: sort by a repeating enum, change some records in an unrelated way, issue the identical query: different order.

Same solution: make your sort by the repeating field first, but always ending in a unique field.

--

If you need further help here, we'll need you to get much more specific about what you're see, what database you're using, the field(s) you're sorting and the values for those fields, any ResultSet settings that aren't defaults, etc.

[smartiro]

Thanks for checking on this. It's not sql dataset actually.
We have a generic serverType with sorting being handled in the backend by our code - sorting is based on internal logic of entity status progression and not on alphabetical name of the status. E.g. 'Completed' should be after 'In Transit'. What we see is that backend returns data to the grid in the proper order however it displays it in alphabetical order. And it appears that is due to another client side sort being executed on the return data.

[Isomorphic]

Ah, that's not new, that's just a misconfiguration: your declared DataSource says that data is text, so it will be sorted as text. Then "secretly", on the server, you actually have an ordinal.

To fix, you can either:

1. declare the as numeric, with a valueMap mapping stored ordinals to displayed values. Then client sort will match what you're doing on the server

.. or ..

2. declare a sortNormalizer, so the values remain strings, but your normalizer sorts them in a hardcoded order that matches the server's order

[smartiro]

Yes, understood. We have few use cases that can be handled by above. In this particular case it's harder - we already have a valueMap that goes from internal code string to localized label. But the actual internal sorting is on a different parameter associated with this object... We can work through this too, but just looking if we can get a simpler path. Specifically - we're looking for an ability to say 'Do not sort client side' without actually turning off sorting.

[Isomorphic]

We need to recommend against this in the strongest possible terms, but, you can set useClientSorting:false. This is, basically, a very very dumb thing to do, since you will ruin performance.

What we have seen happen 3 times before: you use the setting, it looks fine in dev, so you'll think it isn't serious, then there will be a major impact on prod but you will not connect it to this setting because it will be a long time later, so you will chase down other theories and try to "optimize" other things for weeks, when all that was needed was to undo this change.

Much better to just add the valueMap, which should be pretty straightforward to do even if it involves server data - the DynamicDSGenerator is intended for this (see QuickStart Guide).

if you really really go down this route, make sure to do it only for the specific grid where you have the bad DataSourceand not for any other area of the system.

[smartiro]

Thanks for going in all these details. I'm not seeing a java method for this (unlike, say, setUseClientFiltering) so I'm assuming this needs to be set as an attribute only, correct?
And, just to understand this a little better: currently we use grid.setSort and then grid.fetchData when we want sort to be applied server side and we are doing grid.sort when we want to sort client-side only (we have some fields like that).
This seems to be working fine for us except for the issue we're discussing.
So if we turn off clientSorting even when we call grid.sort it will execute a fetch call to the datasource?

[Isomorphic]

The Java API is on ResultSet (previously linked) but again you really should not set this.

Your idea that different APIs cause sorting in different places is not correct - there is only one definition of the sort configuration, and where the sort is performed depends on the cache state. This is also covered in the ResultSet docs (previously linked).

When you disable client sorting, it means that every change to the data view - sorting, filtering, grouping, whatever - requires a server trip. We have no choice, because you're telling us there's no way to replicate server sort.

Normally, as much of 90% of server traffic and thus database load is avoided, so you are telling SmartClient to go 10x slower, almost as bad as the performance of crude "DataTable"s like Flowbite.

That's why we keep emphasizing: just correct your declarations instead of crippling the framework.