經過對代碼的更深入的跟蹤了解,發現了superobject采用的是平衡二叉樹的方式儲存資料的。
首先看看儲存資料的類
TSuperAvlEntry = class
private
FGt, FLt: TSuperAvlEntry;
FGt和FLt分别是儲存通過比較(比較hash或者比較key的asc)大的儲存在Gt,小的儲存在Lt,是一個二叉樹連結清單。
先上圖

假如有如下Json
"assign": {
"FAreaKey": "FKey",
"FAreaName": "FName",
"FAreaCode": "FCode",
}
按照sosmASC排序模式
1.首先插入的是FAreaKey節點,
2.然後插入的是FAreaName時跟Root就是FAreaKey進行比較那他會插入到FAreaKey對應的節點的Gt下圖形A1表示
3.然後插入的是FAreaCode跟FAreakey比較時為較小的插入到LT下面如圖A2表示
4.A2圖已經為平衡二叉樹。
再看看按sosmAdd排序模式
按照sosmAdd的模式的話都是排在後面也就是都放在GT位置
3.然後插入的是FAreaCode跟FAreakey比較時因為GT位置已經有了FAreaName,此時再跟FAreaName比較也是為大的插入FAreaName的GT下面如圖B1表示
4.如圖B1表示經過平衡二叉樹後變成了B2樣式。
這樣查找的話,因為sosmAdd的查詢時都是查找GT位置,不會查找LT分支,是以查詢FAreaKey時會查詢不到。
是以簡單的辦法就是如果安裝sosmAdd方式存儲是不進行平衡二叉數,這樣所有的資料都儲存在GT位置。這樣就成為了一個連結清單的方式,這樣可以從頭查到尾。必然可以查到。
*****深入研究後發現查詢時之前的不區分Key的大小寫的修改其實很容易做到。
最終的Insert代碼為