Understanding grid paging, caching, selection and "Can't select that many records"

[fhisg]

I understand I get "Can't select that many records at once" if I try to select all records (by clicking checkbox in list grid) in combination with paging if there are more records on the server than were fetched in the client.

I'd still like to see a feature that can support that without resorting to odd hacks but that's a different story (another reference).

However, I don't understand this observed behavior (default page size 75):

• opening list grid with more than 75 records, select-all not allowed (warning)
• scrolling to the end of grid and having auto-fetch load more data, then select-all works OR
• selecting first record, then scrolling to end and using shift-select on last record works

This does not work if the number of records is "a lot" larger than the page size (e.g. 400 vs. 75).

Why? I thought that if the time between the first fetch (i.e. first page) and the last fetch (scrolling to the end) is smaller than DS cacheMaxAge the records are in cache and thus available for selection?
Is there a cacheSize somewhere that I overlooked in the DataSource/ListGrid Javadoc?

Could someone please provide some insight or point me to respective resources, thanks.

[Isomorphic]

The ResultSet maintains a sparse list of loaded rows. So you can, for example, have rows 0-75 and 325-400 loaded, which is still a partial cache in which "Select All" is not possible client-side.

[fhisg]

The ResultSet maintains a sparse list of loaded rows. So you can, for example, have rows 0-75 and 325-400 loaded, which is still a partial cache in which "Select All" is not possible client-side.

Ok, thanks a lot for this explanation. Given that, is there any way based on the current implementation we could achieve select-all with let's say 400 records other than setting the page size to 400?

[Isomorphic]

You could make it so that your "Select All" button forces all data to be loaded before actually proceeding with selection. This way you don't have to load data up front, only when the user actually tries to "Select All".

Or you could treat "Select All" as a special state managed by an external checkbox, and when you are in the "Select all" state you disallow normal row-by-row selection. This works for certain UIs.

Finally there is maintaining a selection model on the server and updating it every time selection occurs. A lot of code obviously, as well as a large per-user memory footprint on the server.

[fhisg]

You could make it so that your "Select All" button forces all data to be loaded before actually proceeding with selection. This way you don't have to load data up front, only when the user actually tries to "Select All".

This is certainly the most appealing of the three and I've thinking along these lines before. However, since you seem to somehow disable the checkbox in the header if select-all isn't possible (warning shows on hover) I can't just attach a HeaderClickHandler and load all data. What was your idea for that?

Or you could treat "Select All" as a special state managed by an external checkbox, and when you are in the "Select all" state you disallow normal row-by-row selection. This works for certain UIs.

Something like this seems what I saw here

Finally there is maintaining a selection model on the server and updating it every time selection occurs. A lot of code obviously, as well as a large per-user memory footprint on the server.

Yeah, won't go down that road, but thanks for listing it anyway.

[Isomorphic]

We'd recommend disabling the built-in UI for Select All and adding an external "Select All" button. It's not just that you'd need a HeaderClickHandler or similar, you need to decide whether the data volume is too high to load everything, inform the user if so, trigger the fetch and wait for data arrival, etc.