API already supports the notion of the item sort order (internally its a float, because that makes it much easier to insert items in the middle of the list)

@Tgr, also, take a look at how ordering is implemented in other api modules
(usually using "dir" param)

In T91017#1111584, @Yurik wrote:

API already supports the notion of the item sort order (internally its a float, because that makes it much easier to insert items in the middle of the list)

The drawback is that manual ordering might break due to limited float precision. If insertion is done via order = ( prev + next ) / 2, then (given that MySQL float uses 23 bits for the fraction) order might get swapped after 23 rearrangement actions in the worst case (e.g. user repeatedly moving new items to the second position). I guess that's rare enough to ignore.

@Tgr, it is very easy to catch those, and if the difference between prev and next becomes less than some min value, update can simply change sorting value for a few more row. Not a big deal.

I'm not sure it's worth implementing both kinds of updates. If we implement a method to update gli_order for all rows, we can just use that all the time, adding another kind of insertion logic is just unnecessary complication.

I didn't say you should update all rows - you simply update a few surrounding rows, without the whole list, in the worst case. This is about efficiency - updating 5000 pages in someones list just because they decided to move a page into the beginning of the list is not acceptable perf wise - not only would you update the database for 5000 rows, you would also cause replication for all slave DB servers. Not good :)

How would you identify the rows which need updating? Seems hard to do without failing in some edge cases (not that that's necessarily a big problem).