double fetch when filtering a scrolled grid

[claudiobosticco]

SmartClient Version: SNAPSHOT_v11.1d_2017-03-25/AllModules Development Only (built 2017-03-25)

Chrome on OSX

Hello, please try the #fetchOperationFS sample with showFilterEditor:true
Scroll the grid so that it does some fetches. Then type 'cover up tape' in the category column, and press the filter button. You'll see two fetches, the first with startRow and endRow like:
startRow:20, endRow:95,
the second with 0-75.
If you try #adaptiveFilterFS sample, it does not do a double fetch.

[Isomorphic]

We are able to reproduce this and it does look like the fetch with the larger row position isn't needed. However, since it's just a non-severe performance issue, it's not a top priority.

[Medioman92]

We are facing the same problem but in different context.
i've a grid bound to a DMI which load paged data through a SOAP API (not Java).

The scenario is the following:

1. The application start and the grid loads the first 75 records using DMI (startRow: 0, endRow: 75)
2. The user scrolls down and the DMI provide further 75 records (startRow: 75, endRow: 150)
3. Now the user applies some filters using the grid's editor (for example we expect 30 total rows)
4. The DMI send the criteria and the paging parameters to the SOAP Service
5. The Soap service replies with 500 ERROR because the criteria produces 30 rows in output but we are asking for 75 records (startRow: 75, endRow: 150)
6. The DMI catches the exception and setFailure to the DSResponse
7. A warning popup appears to the user
8. The second fetch will never occurs because of the status -1

According to this case i don't think is't correct to consider this BUG as "performance issue"

[Isomorphic]

There is no way for the client to know that only 30 rows will be available when the criteria is changed. The bug here is actually that your server-side code should be handling the error from the SOAP service and instead either returning empty data (with correct startRow/endRow/totalRows values), or shifting the range so it is from 0 to maxRow available (the latter is preferred, as it will allow the grid to avoid another fetch).