Sent: Friday, November 29, 2013 7:44 PM

我直接創建document的時候，是在一個test report里面做的，如果沒有加commit work，document創建了之后就get不到，加上才work。

Host BO 和其attachment的relationshi是通過 GOS 維護的。

只有代碼里出現COMMIT WORK, GOS的方法才會在新的update process里被觸發。要debug必須打開update debugging。

[外鏈圖片轉存失敗(img-p18C8WYx-1563690249217)(https://user-images.githubusercontent.com/5669954/32708070-faa50bc2-c862-11e7-8efd-0f311fd0cf84.png)]
真正的link是在這里存的，如果沒有commit work，這些代碼都不會被執行到：

IC 點了end button存BO和interaction的link，也是用的類似的辦法，由application call 一個commit,會trigger Genil的框架執行一次commit work。
[外鏈圖片轉存失敗(img-iVauU0BJ-1563690249219)(https://user-images.githubusercontent.com/5669954/32708072-fb1263ac-c862-11e7-9b95-f211aa2eaf6b.png)]
我找到我們social post和service request behavior 不一致的原因了。

問題就出在紅色的這個FM我們沒有enhance：

它會判斷當前的BO在DB是否存在，根據結果決定是否需要一個顯式的commit：
[外鏈圖片轉存失敗(img-YNAXKloF-1563690249220)(https://user-images.githubusercontent.com/5669954/32708075-fb7a1b6e-c862-11e7-94c7-1bd283fff4a0.png)]
我們的socialpost落到了WHEN OTHERS里，因為也不是social post，所以就默認為ev_exist = false. 所以總是需要顯式call commit work 才能真正刪除掉link。

所以我們要么enhance上面那個FM，要么繼續在我們的code里使用COMMIT WORK
同樣的代碼，輸入參數是service request和我們的social post，行為不一致。代碼對我們來說很陌生。

于是我用SAT 分別跑兩個結果出來，一對比，很快就找到了root cause。

右邊是我們的case，紅色的FM是不應該出現的。稍稍分析就能知道為什么它被錯誤的調用到了，從而也就找到了root cause。

上次那個debug的練習后來你找到結果了么？
[外鏈圖片轉存失敗(img-YsgYj6AD-1563690249221)(https://user-images.githubusercontent.com/5669954/32708077-fbe8f340-c862-11e7-90c5-5ede288dc95a.png)]

總結

以上是生活随笔為你收集整理的attachment delete deletion commit work issue的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。