12.0p: ListGrid null value sorting bug depending on ResultSet partially or loaded

[Blama]

Hi Isomorphic,

please see this modified sample (v12.0p_2020-01-07). You'll notice that:

• Rows with empty unit field are at top
• Total rows are 235
• Scrolling down issues requests for next 75 rows a few times as expected
• While this happens sort does not change (as expected)
• When the last page is requested (rows 225 - 235), a resort happens and rows with null in the unit field are moved to bottom (unexpected)

and:

• If you enable dataFetchMode: "local", the second sorting with nulls last is active directly from the start, while the data returned are again in the order where the rows with data in the column are last (unexpected)

Tested on Chromium 79 and FF 26.

I'm not sure which behavior is correct here, but the sorting should definitely not change while scrolling.
As it is not clear that all DB will behave the same by default w.r.t. NULLS FIRST/LAST this somehow relates to this old feature suggestion of mine.

isc.ListGrid.create({
    ID: "supplyItemList",
    dataSource: "supplyItem",
    // dataFetchMode: "local",
    sortField: "units",
    canEdit: true,
    width: "100%",
    height: 550,
    autoFetchData: true,
    initialCriteria: {
        _constructor: "AdvancedCriteria",
        operator: "or",
        criteria: [{
                fieldName: "category",
                operator: "equals",
                value: "Computer Consumables"
            },
            {
                fieldName: "category",
                operator: "equals",
                value: "Canteen and Washroom Products"
            }
        ]
    }
});

Best regards,
Blama

[Blama]

Hi Isomorphic,

actually I think you don't need to implement the feature mentioned in order to fix this for all possible cases.
It should be enough to be able to define how the DB is going to return nulls (FIRST/LAST) in case of sorting ASC/DESC in the Browser with some static method before actually loading the application.
But unfortunately both this and the mentioned feature wouldn't even solve all cases, see below.

This problem might also relate to this thread which is about CI/CS sort where there is basically the same difference.
I think much of the confusion I had when scrolling in the sample is related to your sentence in the linked post:

Yes, we always use a client-side sort whenever we get a complete cache.

Without this extra clientside-sort, order would not change until the user manually clicks a column header.
If in the case of a complete cache here the server and client sorting don't work the same, I think this is OK - I heard no complains so far. But resorting while scrolling is confusing IMHO.

Best regards
Blama

[mathias]

Hey Blama, tried to reach you at your @gmx address. Would like to talk, is it possible to reach you somewhere?

[Blama]

Hi mathias,

did not see it or perhaps deleted it accidentally. Please try again @gmx.net

Best regards
Blama