如果进行数据查询
http://YourVersionOne/rest-1.v1/Data/Story?sel=Order,ID&sort=Order，
您将以降序获得故事的自然创建顺序。
有两种操作：1）在某些故事之前插入和2）在某些故事之后插入。
给予
I）假设我正在检查按降序排列的故事列表。在这种情况下，使用单词“ before”意味着较小的订单号。
II）假设一个零散的故事列表，形式为[...-（x + c），-x，x + c ...]，其中不能保证该列表中有连续的订单号。
III）可能出现负订单号
IV）我以降序作为解释的基础，“越小订单号越好”是任意的。上升参考系同样有效。
示例1：在之前插入
我想在我的故事：1234之前插入我的故事：9999。查询之后，我发现
故事：9999的订单为454
故事：1234的订单为2048
这是我需要通过VersionOne中的REST执行此订单更改的条件
VersionOne URL： https://myVersionOne/rest-1.v1/Data/Story/1234
方法：开机自检
有效负载： <Asset>
<Attribute name="Order" act="set">454+</Attribute>
</Asset>
最终结果是
Story：1234的订单<Story：9999。
我没有给您确切的订单号的原因是因为我注意到了几件事
a）该操作可能会强制Story：1234劫持原始Order（454），并将Story：9999碰撞到下一个可用插槽并碰撞其居民（在固定阵列方案中，Ala插入排序）
要么
b）该操作可以向分配Story1234插入一个满足unusedOrderNum <Story：9999.Order条件的未使用的订单号。这样可使Story：9999保持相同的订单号。*注意：这些空插槽来自删除。
示例2：在之后插入
我想在我的Story：1234之后插入我的Story：9999。进行查询后，我发现
故事：9999的订单为454
故事：1234的订单为2048
这是我需要通过VersionOne中的REST执行此订单更改的条件
VersionOne URL： https://myVersionOne/rest-1.v1/Data/Story/1234
方法：开机自检
有效负载：
<Asset>
<Attribute name="Order" act="set">454-</Attribute>
</Asset>
最终结果是
Story：9999的订单数为454
Story：1234的订单数为453
总之，OrderNum +在某些故事s之前插入，而OrderNum-在某些故事s之后插入。
| 归档时间： |
|
| 查看次数： |
693 次 |
| 最近记录： |