 |
1
noNOno Oct 23, 2017
允许延迟写么,先把排序放临时表,然后延迟更新到控制表中.这样可以控制一定时间内频繁拖动只有最后一次写入
|
 |
2
workwonder OP @noNOno 你这种方案需要额外引入异步调度任务
|
 |
3
x8 Oct 23, 2017
写风暴是啥？
你拖动的时候不是在内存读写吗 |
|
4
workwonder OP @lizon 我的意思是拖动实时生效，一次拖动，需要改 N 个 task 的 position 字段。同时一个 project 是多人管理的，如果有好几个人拖来拖去，那写操作就比较夸张了。
|
|
5
noNOno Oct 23, 2017
@workwonder 是的,只能想到这个.频繁写的情况考虑用列式存储库(redis)么.
|
|
6
workwonder OP @noNOno 暂时往简单的方向做，尽量兼顾性能。
我还有个方案是在 Project 上添加一个数组字段（ Project.tasks_order, e.g. ['t001', 't002', 't003']），用来保存 tasks 的顺序，这样每次拖动都只用改单个 project 的 tasks_order 属性。这种方法在存储上比较冗余（ Task 上面已经有了到 Project 的外键），同时如果想按 tasks_order 的顺序读取出来，还无法利用数据库做到，需要额外在程序中排序。总之感觉这种方案怪怪的。 |
 |
7
ZnZt Oct 23, 2017  1
|
|
8
workwonder OP @ZnZt 多谢老搭档，其实我的业务实体不是 Project+Task，看来这两个关键词好搜索。
|
|
9
workwonder OP @ZnZt 拖动到目标位置后把 position 设置为前后之和取平均的方法确实也考虑了并实施了，但正如大家都提到的，很快就会消耗完所有能够表达的数字（哪怕支持小数），而且我当时把没有搞那么的的步长，很快就觉得这种机制不靠谱。
文中提到可以在闲时再重拍，避免数字被消耗光，我觉得靠谱。准备再考虑下这种方案。 |
|
10
ZnZt Oct 23, 2017
@workwonder 嗯, 真实场景校验过的方案, 应该没啥问题
|
|
11
ZnZt Oct 23, 2017
@workwonder 现在写前端，写 Python/Django, 感觉是在走你老路啊。不知道还能走多久 =。=
|
|
12
workwonder OP @ZnZt 我现在写 Flask+ArangoDB
|
Select Language