大家好，我是米洛，求三連！求關注測試開發坑貨!

回顧

上一篇我們編寫了樹的最外層，但是因為我們還有很深的層級要巢狀，所以我們現在開始。

準備好了嗎？

本文依舊有一定的難度，需要大家理解值傳遞和引用傳遞。

先看看最終效果圖，來點信心。

實現虛擬碼

上一節我們寫的都是虛擬碼，這次直接來實現它。

result是我們最終返回結果。

最外層我們先查詢所有的環境，並生成一個對映關係:

環境id => 環境名稱

為什麼需要env_index

那麼env_index又是幹什麼的呢？

因為環境是最外層，我們需要通過環境id找到我們要往哪個環境的children裡面加第二層的資料，而我們生成的是一個列表，這就導致如果我們需要插入環境id=2的children的時候，不得不去搜索一次result，從result裡面找到id="env_2"的那條資料，接著去append到他的children。

這樣時間複雜度會非常高，但是如果我們提前記錄了，我環境id=2的時候插入到result的第幾個children，那麼就省略了從陣列中查詢的那步，等於用空間（env_idx）換了查詢的時間。

完成第一層資料錄入

可以看到，我們遍歷拿到的PityDatabase資料，接著從env_map裡把環境id轉為環境名。

再開始判斷env_index裡面環境名的索引，在result的第幾個，如果沒有的話，說明result裡面還沒有這個環境的任何資料。

那我們就插入一條環境資料。

result.append(dict(title=name, key=f"env_{name}", children=list()))
 

那此時result就變成了:

[
    {title: "fat", key: "env_3". children: []}
]

這是環境3在result的索引肯定是陣列的最後一個元素，因為我們剛剛才append進去的，所以idx = len(result)-1

接著我們把idx存起來，這個可以理解的吧~

MetaData是我們獲取資料表的關鍵，為了避免重複生成，我這邊只在最外層生成了，傳遞給get_tables方法。

實現內層資料

注意這裡我用get_tables方法的時候，將result[idx]['children']引數傳了進去，意味著後續所有的資料都會append到這個children裡面去，十分方便

而children是個list，list是引用傳遞的。所以我在get_tables裡面對list的改動，其實也是生效的，可以看到get_tables沒有任何返回，那是因為我的result裡頭的children被改掉了，導致了我的result間接被改掉了，就這個道理。

看看get_tables怎麼寫

1. 我們先通過db_helper獲取到當時的連線conn，裡面包含了session和engine，還記得不？

2. 我們再次新建一個list，叫database_child，看名字就知道，他是database再下面一層的資料。

3. 我們編寫當前database層的節點資料，其實就是個dict，title因為我們需要展示對應的資料庫ip+port，所以是這樣:

f"{data.database}（{data.host}:{data.port}）"

因為database有唯一id，所以key可以叫『database_{data.id}』

children即是上一步建立的list().

4. 獲取engine

5. meta獲取表資訊

6. 遍歷表

這邊再次說明一下，get_tables引數中的children，是環境的下一層，database_child是資料庫的下一層，而dbs則是當前層次。

遍歷表了以後，我們臨時建立temp陣列（temp是資料表的下一層，實際上存的是欄位資訊。）

大家如果實在看不明白，以key為標準:

• key以env開頭說明是環境層
• 以database開頭說明是資料庫層
• 以table開頭說明是資料表層
• 以column開頭說明是欄位層

7. 遍歷欄位資料，並把對應的欄位加到temp陣列，因為改了temp陣列，所以實際上database_child(表那一層)也得到了改動。

8. 最終把咱們這一層的dbs->帶有表資料->帶有欄位資料，給加入到剛才傳遞給咱們的children陣列中。

檢視完成資料

這樣前端仔就不會再糾結資料怎麼轉換了，非常好用！

看看實戰效果

由於原生元件提供的圖示啥的都比較粗糙，我們需要進行一下調整。

再來一發效果圖，由於右側的SQL編輯器還在路上，我們就不廢話了。