Skip to content
This repository was archived by the owner on Sep 23, 2024. It is now read-only.
This repository was archived by the owner on Sep 23, 2024. It is now read-only.

Figure out DB schema #80

@veruu

Description

@veruu

It's likely we don't need all the data we now store in the database and it's contents can be largely simplified. This needs to be properly discussed and agreed upon.

For the start:

  • patchtest table looks like a residue of previous functionality where new patches from Patchwork were cross-checked with the DB content. With sending the emails (and eventually setting checks / tags in Patchwork), we shouldn't need it.

  • testrun contains all test runs, while only baseline tests are really checked. We can use baseline_tests instead, or only store required information in baseline table (and update rows after new successful runs)

  • we shouldn't need full history of all tested patches (table patch), combination of last patch info stored with patchwork data and pendingpatches table should be enough to function. With the emails and checks / tags mentioned in the first point, it's useless to keep them

There might be something I'm missing why the above ideas won't work, and other things I haven't mentioned. Let's brainstorm about them and create a new, simpler DB schema and contents.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions