Moving last item up reverses the order of whole scope when 3 last items have adjacent indexes

[ejoubaud]

If order index for the last items are adjacent (e.g. last => 15, last-1 => 14, last-2 => 13), attempting to move the last item up causes the whole scope to be reordred in reverse. For instance:

id  row_order   scope_value
1   9760    1
2   9762    1
3   9772    1
4   9773    1
5   9774    1

Model.find(5).update_attribute(:row_oder, :up)

gives

id  row_order   scope_value
5   -5592404    1
4   -2796202    1
3   0   1
2   2796203 1
1   5592405 1

[savef]

If it's any help you can use this fork: https://github.com/savef/ranked-model (or preferably fork it yourself so it's stable). It fixes some other ranking bugs (see here) but I just tried it with your scenario and it handles it OK.

[brendon]

I just had a sudden reversal of all list items when trying to move the bottom item up. Here's the SQL log:

  Value Load (2.5ms)  SELECT  "values"."id", "values"."row_order", "values"."document_id", "values"."identifier", "values"."ancestry" FROM "values" WHERE ("values"."document_id" = 34 AND "values"."identifier" = 'Criteria 1: Key Indicator 1: Evidence' AND "values"."ancestry" IS NULL) AND ("values"."id" != 501) AND ("values"."row_order" < 8388607)  ORDER BY "values"."row_order" DESC LIMIT 2
  Value Load (0.7ms)  SELECT  "values"."id", "values"."row_order", "values"."document_id", "values"."identifier", "values"."ancestry" FROM "values" WHERE ("values"."document_id" = 34 AND "values"."identifier" = 'Criteria 1: Key Indicator 1: Evidence' AND "values"."ancestry" IS NULL) AND ("values"."id" != 501) AND "values"."row_order" = $1  ORDER BY "values"."id" ASC LIMIT 1  [["row_order", 8388606]]
  Value Load (1.4ms)  SELECT  "values"."id", "values"."row_order", "values"."document_id", "values"."identifier", "values"."ancestry" FROM "values" WHERE ("values"."document_id" = 34 AND "values"."identifier" = 'Criteria 1: Key Indicator 1: Evidence' AND "values"."ancestry" IS NULL) AND ("values"."id" != 501)  ORDER BY "values"."row_order" DESC LIMIT 1
  Value Load (1.2ms)  SELECT "values"."id", "values"."row_order", "values"."document_id", "values"."identifier", "values"."ancestry" FROM "values" WHERE ("values"."document_id" = 34 AND "values"."identifier" = 'Criteria 1: Key Indicator 1: Evidence' AND "values"."ancestry" IS NULL) AND ("values"."id" != 501)  ORDER BY "values"."row_order" DESC
  SQL (0.4ms)  UPDATE "values" SET row_order = -7145850 WHERE "values"."id" = $1  [["id", 496]]
  SQL (0.8ms)  UPDATE "values" SET row_order = -6524472 WHERE "values"."id" = $1  [["id", 495]]
  SQL (0.8ms)  UPDATE "values" SET row_order = -5903093 WHERE "values"."id" = $1  [["id", 494]]
  SQL (0.3ms)  UPDATE "values" SET row_order = -5281715 WHERE "values"."id" = $1  [["id", 492]]
  SQL (0.3ms)  UPDATE "values" SET row_order = -4660337 WHERE "values"."id" = $1  [["id", 491]]
 ...
  SQL (1.1ms)  UPDATE "values" SET row_order = 5903094 WHERE "values"."id" = $1  [["id", 409]]
  SQL (0.5ms)  UPDATE "values" SET row_order = 6524473 WHERE "values"."id" = $1  [["id", 406]]
  SQL (0.5ms)  UPDATE "values" SET row_order = 7145851 WHERE "values"."id" = $1  [["id", 315]]
  SQL (0.4ms)  UPDATE "values" SET row_order = 7767229 WHERE "values"."id" = $1  [["id", 316]]
  SQL (0.6ms)  UPDATE "values" SET "row_order" = $1, "updated_at" = $2 WHERE "values"."id" = $3  [["row_order", -7767228], ["updated_at", "2017-05-01 02:11:04.640457"], ["id", 501]]

I found it strange that the ordering is "row_order" DESC as I assumed the default ordering would have been ASC and that's how I order things in my app.

It looks like this is a rebalancing. Is there a way to configure the default order direction for the position column?

[brendon]

@savef, did you attempt creating some PR's for your fixes?

[brendon]

Looks like #110 fixes this issue.

@jmchambers, @mpokrywka and @mixonic, would we be able to work together to get this merged with this test: 37e19f8?

[savef]

@savef, did you attempt creating some PR's for your fixes?

I can't remember but it doesn't look like it. I can't remember why not but it probably wasn't a good reason!

[brendon]

Haha! That's all good. Hopefully we can get this one accepted soon in any case :)