問題描述

PPR里可以維護不同的item

[外鏈圖片轉存失敗(img-kgQ9SSXA-1563588671269)(https://user-images.githubusercontent.com/5669954/32686310-95b9f244-c6dd-11e7-9b97-314bb20c717c.png)]

選中某個item后能為該item維護1到多個rule

每個rule可以維護1到多個parameter, 例如下圖:
[外鏈圖片轉存失敗(img-k4pziMcX-1563588671270)(https://user-images.githubusercontent.com/5669954/32686312-96266e42-c6dd-11e7-8045-4864b3ac1e0f.png)]
Item1維護完畢之后關閉popup window，再打開item2，當試圖維護item2的rule時: 一旦從dropdown list里選擇某個parameter之后：

系統的behavior 就非常怪。
n 有的時候選了dropdownlist后沒有任何變化
n 有的時候選了dropdownlist之后一下多出來好幾個空白行
n 有的時候選了dropdownlist之后，parameter value column自動填入一些奇怪的值(這些奇怪的值是突破口)
n 選中rule1 點刪除，結果刪除的behavior是”undefine”的，比如rule1并沒被刪除，結果其他rule被刪除掉。
n 。。。

后來我發現這些奇怪的值是突破口，比如我維護item2的rule時，自動帶出來的value似乎和item1已經維護的一樣，但是這個自動帶出來的問題也并不是總能重現，也就是說有的時候是工作正常的，有的時候是不正常的，當我debug了半天發現自己debug的是正常的case時，沮喪。。。

然后我首要任務想的就是如何讓這個錯誤能夠總是重現– 采用“錯誤放大法”。
最后在插入一個我自己寫了很多邏輯的方法print_item_rule （line 26）之后，發現這個問題每次都能重現了！

我是怎么想到在這個地方加，而不是其他地方加？應該是憑經驗和直覺。同時我在所有可疑的地方都加了log:

在仔細研究了海量的log之后，終于發現在維護item2時，從dropdownlist里面選擇了一個field name之后，本來屬于item2的children bol entity居然變成了item1的（這種說法不太準確，應該是說item2的children bol entity，就是當前頁面上正在編輯的bol entity的guid和parent guid全部和item1的entity一致了）！這就是為什么ui上看到自動帶出來的parameter value和item1的一致的原因。

item1: 5CF3FCDC6E521EE483913D1CCAAA1871
rules: 5CF3FCDC6E521EE483DCDE9762BE1038
{O:3912*\CLASS=CL_CRM_GENIL_CONTAINER_OBJECT}

-rul1: 5CF3FCDC6E521EE483DD0B877DC0D0A8
-rul2: 5CF3FCDC6E521EE483DD0BF7F0B750A8
-rul3: 5CF3FCDC6E521EE483DD0C2B8FFFD0A8

item2: 5CF3FCDC6E521EE483913B6999D03870
rules: 5CF3FCDC6E521EE483913EBE06851871

item3: 5CF3FCDC6E521ED483CE91467E8D8D34
rules: 5CF3FCDC6E521ED483CE9578CBFF8D35, parent = item id

然后我就轉而需要知道在什么時候，哪段代碼里發生了這種奇異的事情。經過了周五和周六的漫長debug過后，
還是沒找到原因，后來腦子太混亂了，就離開電腦，在紙上把思路寫下來，然后出去轉了一圈回來繼續，結果兒子在紙上亂畫。。。
[外鏈圖片轉存失敗(img-R5E3eoe0-1563588671272)(https://user-images.githubusercontent.com/5669954/32686296-92aa8730-c6dd-11e7-8ddf-cf37f7deadc5.png)]

[外鏈圖片轉存失敗(img-Fk6N4iWw-1563588671273)(https://user-images.githubusercontent.com/5669954/32686297-92e1c4fc-c6dd-11e7-86e0-5265dd1c5922.png)]
最后在周六午夜的時候，終于找到原因了，這是PPR design的issue。
PPR rule parameter 這個node采用的key structure如下，這個key structure并不能保證不同item的不同rule的不同parameter能夠唯一標識。

換句話說，如果不同item使用了同一個rule set來定義rule parameter( TABLENAME相同)，且從dropdown list里選擇的parameter name 相同(FIELDNAME相同)，且相同name的rule的相對位置也相同(NUMBER_INT相同)，則框架會認為這兩個rule為同一個instance，這是產生上述描述各種混亂行為的根源。

[外鏈圖片轉存失敗(img-P8JES4iL-1563588671275)(https://user-images.githubusercontent.com/5669954/32686299-9347f042-c6dd-11e7-8008-9f2bca4d22d3.png)]

[外鏈圖片轉存失敗(img-27WG5FQN-1563588671276)(https://user-images.githubusercontent.com/5669954/32686300-937ff686-c6dd-11e7-962b-d10e793036a1.png)]

驗證也很簡單，只要我們給三個item維護rule時按照上述規則避免出現duplicate key，此時系統就工作正常。比如采用下列的組合：
item1: valid from “valid from item1”
item2: valid to “valid to item2”
item3: valid from date “2014.7.20”

這個問題從根本上解決也很容易，在key structure里加個guid即可。睡覺！
[外鏈圖片轉存失敗(img-YHqiYFLi-1563588671277)(https://user-images.githubusercontent.com/5669954/32686302-93e34ae2-c6dd-11e7-93bc-59d1b1e4ea34.png)]

[外鏈圖片轉存失敗(img-4C6o9UJ6-1563588671277)(https://user-images.githubusercontent.com/5669954/32686303-941b663e-c6dd-11e7-892a-766f0b59864c.png)]

[外鏈圖片轉存失敗(img-91eJINtf-1563588671278)(https://user-images.githubusercontent.com/5669954/32686304-944e77fe-c6dd-11e7-8011-32e1d5376efa.png)]

[外鏈圖片轉存失敗(img-BA9HYqLf-1563588671279)(https://user-images.githubusercontent.com/5669954/32686306-94ea29e2-c6dd-11e7-8853-8d260e7fd215.png)]

[外鏈圖片轉存失敗(img-n8BbMAeI-1563588671279)(https://user-images.githubusercontent.com/5669954/32686307-951c05f2-c6dd-11e7-8fa2-032c14a28942.png)]

[外鏈圖片轉存失敗(img-MNcF0rTA-1563588671280)(https://user-images.githubusercontent.com/5669954/32686308-9553f444-c6dd-11e7-979d-2e547fc78b2e.png)]

[外鏈圖片轉存失敗(img-b5lMZ0tT-1563588671281)(https://user-images.githubusercontent.com/5669954/32686309-95864a52-c6dd-11e7-9eea-0fde3a6dd4ee.png)]

總結

以上是生活随笔為你收集整理的1536299 2013 - PPR item change - Genil mode的全部內容，希望文章能夠幫你解決所遇到的問題。

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