Remember initial order of list while editing it

Question

The table

Let's say we are running a webapplication for the Superhero Association. In there, there is a table of 1 000 000 super villains which need to be watched. Everytime a super hero gathers new information about villains he updates the table.

The table itself is paginated, sortable and filterable.

Example

The user is on the first page of the table, all over there are 1 400 results, displayed are the first 5 results, sorted by strengt. A request is sent to the backend, it delivers the first 5 results.

Inital view

The users edits the last two entries.

View before page switch

The user now switches to the next page. Again a request is sent to the backend to retrieve the next 5 super villains.

Problem

Since the list is sorted by strength and the user edits strength, the order changes. In this example, that means two things: The user stumbles again over the entries already edited + he skips the entries which silently slip on the previous page. Therfor we want to remember the order of the objects in the initial view at all time while editing and switching pages.

Discarded Solutions

• Prefetching all the data. There is a potential of millions of entries, way too much data, that would not work.
• Prefetching only the IDs and then request single ids to retrieve the next full page. Similar concerns, the list might get way too large.

That can't be a problem that only the Superhero Association has, are there any best practices? Thanks in advance!

Answer 1

Step back a bit and look at situation from a cost/benefit perspective:

How much is gained by implementing the feature (or how much is actually lost by not implementing it) versus how much does it cost in development and operations to have this feature?

Most organizations decide that the benefit of having a stable pagination versus occasional duplicates or holes is just not worth the cost of developing it.

You already found some possible solutions and decided they were too expensive compared to the gain (otherwise you'd have implemented one of them.) It is very likely that there just isn't a solution cheap enough to be worth implementing.

If you settle for less than perfect results, there may be simple alternatives which at least prevent some undesirable effects. For example, you may empirically know that no superhero would flip through all pages, most would stop after 5 or 10. So you could get away with caching 50 results with almost no one noticing the cheat.