需要实现拖动排序的需求，目前想到两个方案1. 用date字段，每次拖动更新影响的数据，从出发点到目标点中间的数据就都受影响2. 用number字段递增，比如1000,2000,3000,4000，拖动排序就往中间插值，直到插不了值再往下重新递增更新
也想不到其他方法了，还有就是如果数据一多 这性能不知道怎么样，leanCloud也不支持事务，这中间要有的更新失败怎么办
大家帮帮忙，给个思路谢谢
「拖动排序」是什么需求？
有一个列表，然后用户可以拖动，拖动完就重新排个序？可以自定义一个字段，这个字段就是用来记录数据位置的（通过 set 方法修改这个字段），然后 LeanCloud 有排序的方法。如 query.ascending 和 query.descending。
能这样就好了，这个记录数据位置是什么类型？ 数字？1234？ 怎么set？ 变成1223？兄弟你想简单了一次拖拽就得更新好多数据，123456， 6拖到1后面就得更新23456，拖的越远更新的越多，数据多怎么办
排序这种我做过， 也试过很多数据结构去存，包括array pointer relation这种，要么需要多次查询，要么查询不能保证顺序，需要自己去排序，数据量大了分页又不好做。最好还是觉得，用一个字段保存顺序比较理想，毕竟用户操作，不会在很大面积的数据上进行操作，更新数量还是比较有限反而是查询效率比较重要，用一个字段去做的话，查询分页排序都能搞
我也是这么想的，就盼望着有没有一种算法可以无限插值不影响其他排序，不知道那些清单类的app怎么搞的，上百个任务，我从头拉到尾，也不显得慢
item 之间用浮点数表示顺序号，拖动之后只改被拖动的这一个元素。如果开始的步长就比较大的话（譬如 100），以后基本上不会出现拖动导致前后两个 item 顺序号冲突的。
其实你提到的用到number字段去做排序就可以，number可以存小数，理论上两个数直接可以取足够多个值
是的，带小数＋较大的初始步长，基本上就 OK 了。
确实没考虑到浮点数，理论上用户可能一辈子都拖不到冲突，但程序上来说总是个bug，是我考虑太不实际了吗？不过确实可取，谢谢你们了
按理说应该碰不到冲突的时候，不过要保证程序稳定运行 102 年，你可以在碰到冲突的时候，把冲突点之后的 item 全部增加 100.0，这样又能管几十年了。:smile:
想来想去还是不太对，怎么插值还是个问题100.000这中间插进去是几？200.000300.000
假如这样100
100.009 100.01 100.0.. 100.07 100.08 100.09 100.1 100... 100.8 100.9 101
1.. 198 199200
那一个小数位最多只能10次，100次已经小数10位了，如果来来回回拖就1次就退一个小数位
100.0 和 200.0 中间插进去，就给他赋值 150.0.不是每拖一次就要变一次，而是最终顺序要固定保存的时候才变一次。
用浮点数，在 A 和 B 之间插入就赋值 (A+B)/2，以现代计算机浮点数的精度，基本是可以随便插不太可能遇到问题的。
好像我们面试时出过这道题
这么晚还没睡
var a=1000000000, b=199, i=0; while(true) { b = (a+b)/2; if (b==a) { break; } else { i++; } } console.log(i);
用js测试了下 不管数值多大，都是100内
你这里a和b都还是整数，换成双精度浮点数试试。
一样的，貌似是js精度丢失比较严重的问题 alert(0.7+0.1); //输出0.7999999999999999
(10000.00 + 9999.999999999998)/2.0 = 10000
试了试c# 也是这样,用c#的decimal类型 也就多了几次
想到了办法 PreviousId NextId 这样更新就容易了 但又没办法排序
应该也够用了吧。你是用于什么场景呢？会有多少数据，拖动排序会有多频繁？
类似任务清单，还没见过排序次数有限的app，暂时没办法只能批量更新了
任务清单一般长度不会超过几十吧。其实你就存一个序号，然后根据拖动跨度 update 多行也不会很慢的。
这种方案就太复杂了：http://dba.stackexchange.com/questions/5683/how-to-design-a-database-for-storing-a-sorted-list
谢谢你分享的这个链接
暂时选择update多行，拖完点完成再update，还必须有个菊花，不然快速点退出再打开可能拿到未更新前的状态
我考虑到另一个方法感觉也是可行的，看了下印象笔记的同步规范文档，维护一份本地数据副本，记录更改，再后台同步，这样就不怕更新慢或者怎么滴，因为嘀嗒清单也是用同步的方式，估计也是这样
