refer to
標準資料來源的delta機制概述
1. 所有的delta資料，在傳輸到bw之前，都會先到delta q， 再到bw。delta q可以通過rsa7進行管理和觀察。delta q的乙個重要作用是保證記錄的順序。
2. delta資料從原始表到delta q，有兩種情況：對於lo的資料來源，是系統將delta資料push到delta q的，然後在infopackage執行的時候，再把資料從delta q搬到bw。 對於非lo的資料來源，大部分採用time stamp的方式，在infopackage執行的時候，系統根據time stamp去源資料表獲得delta資料，這些資料被送往delta q之後，緊接著就被搬到bw了。所以，對於非lo的資料來源，你很難在delta q裡看到他們的delta 資料。
3. 對於time stamp的delta 方式，大部分資料來源（全部？）的time stamp 記錄在表bwom2_timest中。
4. 對於lo資料來源，其delta資料流根據選擇的_updatemode不同會有所區別，後面詳述。
5. 系統如何獲取delta 資料，跟資料來源的delta process 有關，後面詳述。
關於delta process
每乙個資料來源，都有乙個很重要的屬性：delta process . 在rsa2中可以看到：
此外，你也可以在表roosource中找到該資訊。
delta process 告訴我們系統是如何捕獲delta 資料的。一般來說，delta資料有新增，修改和刪除幾種情況。新增就是直接把這條資料作為delta資料，刪除一般是生成一條方向資料(reserve image)。修改，就有點複雜了，大概有幾種不同的處理方式：
after image 即只捕獲修改後的資料作為delta資料。
add image 則是捕獲修改之後的資料與源資料之間的差。
before image則生成一條原來的資料的反向資料，用來沖銷原先的資料。
bw資料來源，大概有有以下的delta process:
這 些delta process都是如何捕獲delta資料的呢？表rodeltam可以告訴我們其中的奧秘。這張表記錄了每個delta process 是採用何種映象去捕獲delta資料的，是否對保持記錄的順序有要求。不同的映象方式，對bw的建模和資料流是有很大影響的：
若 採用before image, after image, reserve image的方式，例如：abr（dso的change log也是這種方式），則資料既能覆蓋（覆蓋的時候after image覆蓋掉了之前的before image），又能累加（累加的時候，before image沖銷原來的記錄，after image則是修改後記錄），可以增量更新到dso和infocube。
若只支援after image, 則資料只能覆蓋，不能累加，例如：aie，則只能先增量更新到dso，再更新到infocube。這種情況，一定要在datasource 和 cube之間有一層dso.
若只支援add image,例如:add，則資料只能累加不能覆蓋。這種情況下，通常沒有dso層，如果需要dso層，則注意要將transformation設定為累加模式。
若是full only, 要實現delta必須通過infopackage的設定來近似實現。
flex Bindable深入研究
bindable 元資料標籤，它在 中的作用就是向編譯器提供如何編譯程式的資訊。它的最大作用是使程式元件間的資料同步變得容易。在開發中通常用上bindable作用在檢視控制項上，如給它繫結乙個物件，則以後只需要在邏輯層更改這個物件的值，則檢視層的控制項資料會自動更新 同步 而不再需要手動去更新檢視。...
URLRequest深入研究
urlrequest 的乙個例項 html view plain copy create the request.所構建的nsurlrequest具有乙個依賴於快取響應的特定策略，cachepolicy取得策略，timeoutinterval取得超時值 nsurlrequest therequest...
深入研究AsyncTask
asynctask提供了一種在後台執行操作而在ui執行緒顯示結果的方式,而且開發者不必操作執行緒或者handler.乙個asynctask定義了三種泛型分別是params,progress,result,還有四個函式分別是onpreexecute doinbackground onprogressu...