10.1p/12.0d ListGrid with sortByGroupFirst:true that is too big to group fires two requests

[Blama]

Hi Isomorphic,

please see this sample (v10.1p_2017-08-03, also happening in 12.0d) and modify it like this:

isc.ListGrid.create({
    ID:"dsListGrid",
    width: "100%",
    height: "100%",
    minFieldWidth:80,
    autoFetchData: true,
    dataSource: "supplyItem",
[B]  sortField: "SKU",
    groupByField: "category",
    sortByGroupFirst: true[/B]
});

As you will see, it fires two requests with different sorting criteria

• 0-1000 (sortBy: category, SKU) and afterwards
• 0-75 (sortBy: SKU)

So it discards the 1st big one and scrolling will again request data.. I don't think that this is on purpose and would suggest to always keep sortByGroupFirst-field, even if the grid is too big to sort.

Minor and unrelated: For me (Win 10, Chromium 60, no zoom, FullHD) the request for the unmodified sample is for startRow:0, endRow:87 and not endRow: 75 as I'd expect (and as it is in 12.0d).

Best regards
Blama

[Isomorphic]

You've configured grouping on a dataset too big to be grouped, but the grid can't know this without contacting the server. It contacts the server and retrieves up to groupByMaxRecords, hoping the dataset will be small enough for grouping. Since it isn't, the grid has to discard the loaded data, because when not grouped, the sort is different, and the server cannot perform a client-side sort since there is partial data.

Nothing to fix or improve here in the framework, that we can see. If this is your situation and you're trying to avoid the large initial fetch, check the dataset size *before* configuring grouping on the grid.

Also, as to number of rows fetched: large screen size + drawAhead ratio settings can cause more than the dataPageSize rows to be fetched. Also expected.

[Blama]

Hi Isomorphic,

on the main issue: yes and no.
This is my use case:

• Imagine you want to group all countries by continent and then have a) the groups sorted b) the countries sorted and are displaying both continent and country as field
• You use
  sortField: "country",
  groupByField: "continent",
  sortByGroupFirst: true
• Expected output is:
  • Africa
    • Africa-Algeria-...
    • Africa-Angola-...
    • Africa-Benin-...
• Now when the ListGrid gets too big to sort I get this (sorted by country, only):
  • Asia-Afghanistan-...
  • Europe-Albania-...
  • Africa-Algeria-...
• But I still want the top of the list to look like this:
  • Africa-Algeria-...
  • Africa-Angola-...
  • Africa-Benin-...

IMHO This is the reasonable and expected fallback as it matches the layout of a smaller data set.
The end user does not care about some technical groupByMaxRecords setting and only wonders why besides the grouping row missing, also the sort is broken.

If you disagree, this would definitely be a nice additional setting because it seems logical.

Best regards
Blama

[Blama]

Also, as to number of rows fetched: large screen size + drawAhead ratio settings can cause more than the dataPageSize rows to be fetched. Also expected.

The reason I'm reporting this is that the requests differs for the original sample and the small sample change from #1.

Best regards
Blama

[Isomorphic]

We definitely do not agree that the ListGrid should apply grouping-related sorting properties even when not grouped.

If you want this particular sort order when grouping is not possible, use the approach we covered above of checking the dataset size first, then applying that sort if grouping is not possible. That's also much more efficient than the ListGrid is in a position to be, since the grid has no way of knowing that this dataset will frequently be larger than the max client-side grouping size.

As far as the fetchSize, again it can differ by screenSize, and by drawAheadRatio and other settings, which can also vary per skin or per release. If you think there's a bug here, you would need to explain how you are calculating that the necessary fetch is really just 75. You can do that in a new thread if you like.

[Blama]

Hi Isomorphic,

If you want this particular sort order when grouping is not possible, use the approach we covered above of checking the dataset size first, then applying that sort if grouping is not possible. That's also much more efficient than the ListGrid is in a position to be, since the grid has no way of knowing that this dataset will frequently be larger than the max client-side grouping size.

I'll go down that route then as soon as I get a user-complaint about the sort.
As general improvement suggestion for the "too many rows for grouping"-case:
If the server knew about groupByMaxRecords, it could stop right after the COUNT(*) query and then return a very small "please requery" to the client or - even better - a partial DataSet that the client can work with.
This way the 100kb, that are currently transferred for me, and then directly discarded, are not wasted.
This would require knowledge on the server about:

• which sortBy fields are from sort and which from grouping
• how many records it should return (so an alternative to endRow:1000)

For me, this is minor, but it might be a low-priority enhancement for you.

As far as the fetchSize, again it can differ by screenSize, and by drawAheadRatio and other settings, which can also vary per skin or per release. If you think there's a bug here, you would need to explain how you are calculating that the necessary fetch is really just 75. You can do that in a new thread if you like.

OK, will do so.

Best regards
Blama

[Isomorphic]

That is also something you can do in your application code: make a request to the server that returns either the full dataset or partial, then apply whichever dataset is returned it to the grid via providing a ResultSet, with sort settings as you desire.

[Blama]

Hi Isomorphic,

I'm using Power with your server. In that case how would I stop the server after the COUNT(*) SQL statement and then execute a different request or get a different rowcount.
Sending a count(*) from the client and then deciding how to proceed would add a round-trip.
This only makes sense as a built in product feature IMHO.

Best regards
Blama

[Isomorphic]

You would simply execute multiple DSRequests from a single DMI, so there's only one request from the browser.

[Blama]

Slightly related thread here.