Again the behavior we are talking about is whether an update to a record that is not currently cached *should pop to the top of a ListGrid by default*.
In both scenarios you describe, if there is an update to a record that is not currently visible to the user because it hasn't been loaded, they can discover it by scrolling down - in exactly the same way they would discover it if it had not been updated.
But to anticipate your next confusion - in both cases you are touching on the possibility of real-time updates. But if the behavior of ResultSet were changed to what you expected, it would not actually handle the real-time update scenario, nor would it bring you any closer to solving it, because:
1. when updatePartialCache is active,
The cache will then be dropped the next time rows are fetched, to prevent problems with inconsistent row numbering between the server and client, which could otherwise lead to duplicate rows or rows being skipped entirely.
2. if real-time updates are being pushed, there have to be limits on total number of rows retained or the application will eventually run out of memory. Here again, the ResultSet does not have enough information to impose a reasonable limit.
Because of these factors, both real-time updates and your possibly-related requirements are best handled as we already explained:
Instead, what you might want to do in this use case is to grab the data in the existing ResultSet and create a new ResultSet from it, placing the new row in whatever visual position you prefer.
Leave a comment: