2012-11-28 27 views

回答

4

如果你做一個數據查詢
http://YourVersionOne/rest-1.v1/Data/Story?sel=Order,ID&sort=Order
你會得到降序排列你的故事自然創建順序。

有兩個操作:1)在某個故事前插入和2)在某個故事後插入。

GIVEN

I)假設我檢查降序排序案例列表。在此情況下,使用「之前」一詞意味着較小的訂單號。 II)假設以[...-(x + c), - x,x + c ...]形式出現故事的碎片列表,其中不能保證此列表中的連續訂單號。

III)負面的訂單號可能存在​​

IV)我在看的順序依次爲這種解釋的依據,「小訂單號越好」是任意的。 參考的上升幀同樣有效。

例1:將前

我想插入我的故事:1234:我的故事之前,9999。做一個查詢後,我發現

故事:9999擁有454
故事的訂單:1234有2048

這裏的秩序是什麼,我需要通過REST在VersionOne的執行此訂單變更

VersionOne的網址:https://myVersionOne/rest-1.v1/Data/Story/1234

方法:POST

有效載荷:<Asset> <Attribute name="Order" act="set">454+</Attribute> </Asset>

最終的結果是
故事:1234具有訂單<故事:9999

我之所以沒給你的每一個確切的訂單數量,因爲我已經注意到了幾件事

一)操作可能會迫使故事:1234劫持原來的順序(454)和凹凸的故事:9999到下一個可用時隙和凹凸其居民(在固定陣列場景丙氨酸插入排序)

b)中所述的操作可以插入分配Story1234滿足條件的未使用的訂單數unusedOrderNum <故事:9999.Order。這允許Story:9999保持相同的訂單號。 *注意:這些空插槽來自刪除。

例2:插入後

我想插入我的故事:1234:我的故事後,9999。之後做了查詢,我發現

故事:9999擁有454
故事的訂單:1234有2048

這裏的秩序是什麼,我需要通過REST在VersionOne的執行此訂單變更

VersionOne的網址:https://myVersionOne/rest-1.v1/Data/Story/1234

方法:POST

有效載荷: <Asset> <Attribute name="Order" act="set">454-</Attribute> </Asset>

最終的結果是
故事:9999具有454
故事的順序:1234具有453

總之的順序,ORDERNUM之前+插入一些故事S和OrderNum-追加後一些故事。

+0

Still Works 4 years later - Thanks! –