This is the 15th 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 wrote the outermost layer of the tree, but since we still have deep levels to nest, we’ll start now.

Are you ready?

Understanding value passing and reference passing is still a bit tricky.

Take a look at the final image, and feel confident.

Implementation pseudocode

So what we did in the last video was pseudo code, so let’s just implement it this time.

Result is the result that we finally return.

For the outermost layer, we first query all the environments and generate a mapping:

Environment ID => Environment name

Why env_index

So what does env_index do?

Because the environment is the outermost layer, we need to find the data of the second layer in the children of which environment we want to add through the environment ID, but what we generate is a list, so if we need to insert the children of the environment ID =2, we have to search result once. Select * from result where id=”env_2″ and append to children.

This would be very time intensive, but if we had pre-written how many children I inserted into the result when the environment ID was 2, then we would have omitted the query step from the array, which would have changed the query time with space (env_idx).

Complete the first level of data entry

As you can see, we iterate over the PityDatabase data we received and then convert the environment ID to the environment name from env_map.

Env_index (env_index, env_index, env_index, env_index, env_index);

So let’s insert a piece of environment data.

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

In this case result would be:

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

Idx = len(result)-1; idx = len(result)-1

Then we save idX, this is understandable ~

MetaData is the key to getting the table. To avoid duplicate generation, I only generated it in the outermost layer, passing it to the get_tables method.

Implement inner data

Note that when I use get_tables I pass result[idx][‘children’], which means that all subsequent data will be appended to children.

And children is a list, and list is passed by reference. So when I change the list in get_tables, it actually works. You can see that get_tables doesn’t return anything because the children in my result was changed, so my result was changed indirectly, that’s all.

How about get_tables

  1. Db_helper = conn; conn = conn; conn = conn;

  2. Let’s create a new list called database_child, which, as the name suggests, is the data at the next level from database.

  3. We write the current database layer node data, which is dict title, because we need to display the corresponding database IP +port, so it looks like this:

F "{data.database} ({data.host}:{data.port})"

Because the database has a unique ID, the key can be called database_{data.id}.

Children is the list() created in the previous step.

  1. Access to engine

  2. Meta Gets table information

  3. Traversing the table

Again, children in get_tables is the next level of the environment, database_child is the next level of the database, and DBS is the current level.

After iterating through the table, we create a temporary temp array (temp is the next level of the table, which actually holds the field information).

A. key B. key C. key D. key

  • Key that starts with env indicates the environment layer
  • Starting with database indicates the database layer
  • Table indicates the data surface layer
  • Column indicates the field layer
  1. Iterate over the field data and add the corresponding field to the TEMP array becauseChanged the temp arraySo database_Child (the table layer) has actually been changed as well.

  1. Finally add DBS -> with table data -> with field data to the children array just passed to us.

View completed Data

So the front end son will no longer struggle with how to convert data, very useful!

See what happens in action.

Since the ICONS provided by the native component are pretty crude, we need to make some adjustments.

Here’s another illustration, but since the SQL editor on the right is still on the way, we won’t waste any time.