54.数据库表接口适配前端页面(下)

大家好，我是米洛，求三连！求关注测试开发坑货!

📒 回顾

上一篇我们编写了树的最外层，但是因为我们还有很深的层级要嵌套，所以我们现在开始。

准备好了吗？

本文依旧有一定的难度，需要大家理解值传递和引用传递。

先看看最终效果图，来点信心。

📒 实现伪代码

上一节我们写的都是伪代码，这次直接来实现它。

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怎么写

我们先通过db_helper获取到当时的连接conn，里面包含了session和engine，还记得不？
我们再次新建一个list，叫database_child，看名字就知道，他是database再下面一层的数据。
我们编写当前database层的节点数据，其实就是个dict，title因为我们需要展示对应的数据库ip+port，所以是这样:

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

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

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

获取engine
meta获取表信息
遍历表

这边再次说明一下，get_tables参数中的children，是环境的下一层，database_child是数据库的下一层，而dbs则是当前层次。

遍历表了以后，我们临时创建temp数组（temp是数据表的下一层，实际上存的是字段信息。）

大家如果实在看不明白，以key为标准:

key以env开头说明是环境层
以database开头说明是数据库层
以table开头说明是数据表层
以column开头说明是字段层

遍历字段数据，并把对应的字段加到temp数组，因为改了temp数组，所以实际上database_child(表那一层)也得到了改动。

最终把咱们这一层的dbs->带有表数据->带有字段数据，给加入到刚才传递给咱们的children数组中。

📒 查看完成数据

这样前端仔就不会再纠结数据怎么转换了，非常好用！

🍦 看看实战效果

由于原生组件提供的图标啥的都比较粗糙，我们需要进行一下调整。

再来一发效果图，由于右侧的SQL编辑器还在路上，我们就不废话了。