BUG in 11.1 in implementation of refreshData of TreeGrid

[janusz]

Hi,

In 11.1 LGP dates 2018-11-18 in implementation of refreshData there is code that cuts the number of records returned:

        } else if (isc.ResultTree && isc.isA.ResultTree(d)) {
[B]initialData.length = dsResponse.endRow - dsResponse.startRow;[/B]
            // create via ActionsMethods createResultTree() so that all attributes set properly
            resultSetOrTree = this.createResultTree(fetchCriteria, null, d.context, null,
                                                    initialData, true);
            resultSetOrTree.setOpenState(d.getOpenState());
        }

If there are just two rows, startRow should be 0 and endRow should be 1. Initial data is calculated to be 1 while it is 2.
You should use dsResponse.totalRows if it is present..

Additionally refreshData makes a request with sorting set to TreeGrid's sort even for TreeGrids with dataFetchMode set to "local".

Best regards,
Janusz

[Isomorphic]

Is there a particular sample dsResponse you can show where this calculation is wrong? It appears to be correct. Note you need to carefully look at the docs for startRow and endRow: endRow is exclusive. This also means totalRows need not be consulted.

We will address the unnecessary server sort for treeGrid, however.

[Isomorphic]

We've updated refreshData() in SC 11.1p and newer releases to avoid triggering a server sort where not needed. This should be in the nightly builds dated 2018-11-29 and beyond.

[janusz]

I can see now that there is a mention about endRow exclusivity in doc just for DSRequest.endRow, which I was not consulting when I was creating my implementation of DSResponse.

DSResponse.endRow doc just states

End row of returned server results, when using paged result fetching
Note that startRow and endRow are zero-based - the first record is row zero.

so you can interpret it as I did, with startRow: 0, endRow: 1, totalRows: 2 being a response with 2 records.

[Isomorphic]

We've updated the docs for future builds.