attachment delete deletion commit work issue
attachment delete deletion commit work issue
版权声明：署名，允许他人基于本文进行创作，且必须基于与原先许可协议相同的许可协议分发本文 （Creative Commons）
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)]
