This is the 14th day of my participation in the August More Text Challenge.

Hey, it’s Milo. Company three, please! Beg attention test development pit goods!

review

In the last article, we made some effort to change the asynchronous code back to synchronous code, but we can’t say nothing. We wrote the ability to run SQL statements online and return the desired list of fields -> field values.

Today we will improve the page section.

This article is divided into two sections because of its complexity, which is somewhat difficult. I will try my best to explain clearly as a blogger, and you still need to understand more.

How to query the table and specific fields

I think this function is a relatively big highlight. Generally speaking, we perform the test online. Taking the platform I did before as an example, it is only for the purpose of enabling users to execute SQL online, so the display of data tables, fields and so on is abandoned.

Today, we’re going to do a whole block of functionality.

Get the table data from Engine

We all know that we can view table information by executing show tables, but we need not only information but also fields, so how do we do that?

And we also need to pull out all the database configurations oh, no, just watch me do it!

In SQLalchemy, we can use engine.table_names() to get specific table information with fields, and then compare our reference project to get our direction.

What does the back end need to do

Now that we have a rough idea of the UI we want to implement, let’s go to the ant.design website to find the tree component.

So how do we prepare our data? When the front-end is not convenient to process, we can try to return the front-end use of comfortable data. Let’s start with the data the component needs:

const treeData = [
  {
    title: 'parent 0',
    key: '00',
    children: [
      { title: 'leaf 00', key: '000', isLeaf: true },
      { title: 'leaf 0- 1', key: '00- 1', isLeaf: true },
    ],
  },
  {
    title: 'parent 1',
    key: '0- 1',
    children: [
      { title: 'leaf 10', key: '0- 10', isLeaf: true },
      { title: 'leaf 1- 1', key: '0- 1- 1', isLeaf: true},],},];Copy the code

Let’s break it down step by step:

  • At the top

    The top layer is a list with a dict inside (take Python data structures for example).

  • List elements

    The list elements include: title (display name), key(unique identifier, to make it easier to know which element is selected, similar to the CONCEPT of THE CSS ID), children(whether there are children, the same list of children).

    If you have a data that is deeply nested, you might have many layers of children inside of children, and we’re going to deal with that.

Figure out the data the front end needs

In fact, this is very similar to our folder feeling, let me list a directory here to show you.

Fat is the environment, the biggest category, and pity is the name of the database, and pity_testCase is under pity, and then id, name, and so on.

So if we have this data, how do we present it to the front end? According to their rules:

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"
                          // There is no children, because the field is the last level
                      },
                      {
                          "title": "name"."key": "column_name"
                      },
                      {
                          "title": "create_time"."key": "column_create_time"}]}]}]Copy the code

As you can see, the data is layered like this, which can be described as very complex! You may think that if YOU want me to write it manually, but if you want me to generate it according to the data in the database, then I’ll go back and learn the tree.

Actually, Duck doesn’t have to. We just need to think clearly.

Determine the unique key

Fat env: fat env: fat env: fat env: fat env: fat But if we prefix the table name, such as env_1, wouldn’t that string?

What if some data doesn’t have an ID? For example, a table field doesn’t have an ID, but the father of the table, our pity_database_info table, has a unique ID, so we’ll just take the id of its father’s father.

divide-and-conquer

  • Environment Layer (Layer 1)

    First we need to get how many environments we currently have, and get the exact id of the environment -> the corresponding environment name, since our pity_database_info store env

Is the primary key, not the corresponding environment name.

Assuming we have the list of environments, we can create the first layer of data, shown here in pseudocode:

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: []
    })
Copy the code

So we have finished compiling the outermost data.

[{"title": "fat"."key": "env_1",
        children: []
    },
    {
        "title": "uat"."key": "env_2",
        children: []
    }
]
Copy the code

As you can see, the prototype is already there.

Let’s put it in the tree and see what it looks like:

The figure shows two directories, but because there is no children, there is no content in the expanded directory ~

The rest will be solved in the next section!!

The project documentation is at pity.readthedocs.org