测试平台系列(53) 数据库表接口适配前端页面(上)

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

回顾

上一篇我们费了点功夫，将异步代码改回了同步代码，但也不能说一无所获，我们编写好了在线运行sql语句的功能，并返回了想要的字段->字段值的列表数据。

今天我们就来完善一下页面部分。

本文因为比较复杂而分为2节，有一定的难度，博主我也会尽量讲清楚，大家还需要多理解。

怎么查询到数据表和具体字段呢

这个功能我认为是一个比较大的亮点，一般来说我们在线执行测试，就拿我以前做的平台举例，都只是为了能让用户在线执行下SQL，所以对于数据表，字段等的展示都是放弃的。

今天呢，我们就来整一整这块的功能。

通过Engine获取表数据

我们都知道，可以通过执行show tables来查看表信息，但是我们不但要信息，还要字段，那该怎么做呢？

而且我们还需要把所有数据库配置都拉出哦，没事，看我操作就行了！

在sqlalchemy里面，可以用engine.table_names()拿到具体的表信息，而且是带上字段的，再对比一下我们的参考项目，我们就能明确到自己的方向了。

后端需要做什么

我们既然已经看到了大概想要实现的UI，那么我们就去ant.design官网找对应的树组件。

那么我们的数据该怎么准备呢？在前端不方便处理的时候，我们后端可以尽量返回前端使用舒服的数据。先看看组件需要的数据:

const treeData = [
  {
    title: 'parent 0',
    key: '0-0',
    children: [
      { title: 'leaf 0-0', key: '0-0-0', isLeaf: true },
      { title: 'leaf 0-1', key: '0-0-1', isLeaf: true },
    ],
  },
  {
    title: 'parent 1',
    key: '0-1',
    children: [
      { title: 'leaf 1-0', key: '0-1-0', isLeaf: true },
      { title: 'leaf 1-1', key: '0-1-1', isLeaf: true },
    ],
  },
];

我们一步一步来分析:

• 顶层
  顶层是一个列表，列表里面是一个dict（以Python数据结构为例）。

• 列表元素
  列表元素又包括: title（展示名称）, key(唯一标识，为了方便选中的时候知道选到了哪个元素，和css中的id接近的概念), children(是否有孩子，孩子也是一样的列表)。
  如果一个数据嵌套比较深，那么可能会在children里面有很多层children, 接下来我们就要处理这块。

构思出前端需要的数据

其实这个很像我们的文件夹的感觉，我这边列个目录给大家看看。

fat是环境，最大的分类，接着pity是数据库名，pity下面还有pity_testcase（数据表）,数据表下面还有id，name等字段。

那么如果我们是这些数据，要给前端是怎么展示的呢？按照他们的规则:

const treeData = [
{
  title: "fat",
  key: "env_fat",
  children: [
      {
          "title": "pity",
          "key": "database_pity",
          "children": [
              {
                  "title": "pity_testcase",
                  key: "table_pity_testcase",
                  children: [
                      {
                          "title": "id",
                          "key": "column_id"
                          // 这里就没有children了，因为字段是最后一级了
                      },
                      {
                          "title": "name",
                          "key": "column_name"
                      },
                      {
                          "title": "create_time",
                          "key": "column_create_time"
                      }
                  ]
              }
          ]
      }
  ]
}
]

可以看到，数据是这样一层一层的，可谓十分复杂!大家看到可能会觉得，要我手动写还行，要我根据数据库的数据生成，那我还是回去学习了树之后再来吧！

其实duck不必，我们只要理清楚思路就行。

确定唯一key

大家有没有发现，虽然fat这种env是有id的，但是它也可能和其他表的id串了，所以我们是不能以id为key的。但如果我们加上表名的前缀，比如env_1，这样是不是不会串了呢？

那如果有的数据没有id呢？比如数据表的字段数据，其实没事，我们只要带上它爸爸的id即可，比如数据表字段虽然没有id，但是数据表的爸爸有，即我们的pity_database_info表，它是有唯一id的，所以我们带上他父亲的父亲的id即可。

各个击破

• 环境层（第一层）
  首先我们需要获取到当前有多少环境，并拿到环境的具体id->环境名称的对应关系，因为我们的pity_database_info存放的env
  是主键，而不是对应的环境名。
  假设我们拿到了环境列表，那我们可以造出第一层数据, 这里用伪代码展示:

envList = [{"id": 1, "name": fat}, {"id": 2, "name": "uat"}]
result = []
for env in envList:
    result.append({
        title: env.get("name"),
        key: f"env_{env.get("id")}",
        children: []
    })

这样我们就完成了最外层数据的编写，result目前的结果:

[
    {
        "title": "fat",
        "key": "env_1",
        children: []
    },
    {
        "title": "uat",
        "key": "env_2",
        children: []
    }
]

可以看到，雏形已经出来了。

我们去放到树里面看看效果:

图中显示了2个目录了，但是因为没有children的缘故，所以目录展开后是没有内容的~

剩下的就交给下一节来解决了！！！

项目文档地址: https://pity.readthedocs.org