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

Hello, everyone ~ I’m Milo, welcome to pay attention to my public account test development pit goods!

review

In the previous section we looked at how to design the use case table, and since our cases were tied to the project, we will improve the case-related parts in this section.

follow

Previously, there would have been a project_ID and category field in the use case table, representing the project and directory, respectively. We made the directory table in the previous section, so we need to remove the project_id and directory fields and replace them with the directory_id field.

Instead, simply change project_id to directory_id and delete the category field. But this will affect the project list page.

But it doesn’t matter, we were supposed to remove the case page from the project list page.

Rewrite the interface of the query item

Changes on the page:

Plan the list page

Now that the old list page is dead, how should the new list page be displayed?

In the previous section we wrote the case directory, and that use case is associated with the directory, so we can roughly imagine a page like this:

As you can see, the layout is left and right:

  • On the left side of the

    Item selection and directory trees, which, as we dealt with in the previous section, can be nested like crazy. At present, the directory does not support mobile, which is a pity.

  • On the right side

    On the right is a use case list page, a list of use cases in the XXX directory, which also allows you to filter cases by use case name and creator.

    I’m not going to continue to paginate cases here, so the number of cases in a single directory should not be thousands of exaggeration.

What’s next?

To provide this data for the front-end presentation, of course. We currently need to support creator + use-case name + directory for queries.

Directories are nested, so we need to find all the children of the directory. And since there can’t be that many directories, we find the directories to look up and all the non-root directories.

For example, if I want to look up the data in the root directory A, the other root directories must not be the sons of A, but the brothers of A.

If you use layers of for loop to query data, it will certainly affect the performance, of course, I recommend you to cache the query results in Redis, generally we do not change directories easily, delete the cache when replacing, so that it will get twice the result with half the effort.

Taking action

  • Write A method to get all subdirectories under A

  1. First find any data where parent is equal to directory_id or is not the root directory
  2. As before, put them into a map to create a parent -> son mapping.
  3. Write a method to get sons (recursively), putting all child nodes in result
  • Adjust the list_TestCase method

First get all directories under directory_id and then find cases where the directory is undeleted and directory_id is in.

And then if there are other conditions, like name, create_user, and so on, add a filter.

Then sort by case name.

Improving the List interface

The final result

If you just look at the right side, it’s a list page, but the difference here is that it’s connected to the left side of the tree.

By the way, the nuggets more plan to adhere to 21 days immediately, it is not easy ah, the follow-up may be put on the public number of the first article.

Bye bye, the next article will cover how to use Gunicorn deployment, but it will take some time to edit/add/execute the use cases.