Closed Yoronex closed 2 months ago
Commit: 4647064 Base: develop@82c9ffb
Type | Base | This PR |
---|---|---|
Total Statements Coverage | ? | 87.51% (?) |
Total Branches Coverage | ? | 85.46% (?) |
Total Functions Coverage | ? | 89% (?) |
Total Lines Coverage | ? | 87.48% (?) |
File | Statements | Branches | Functions | Lines |
---|
Ugh, another migration issue :(
I guess it might be time to create a testing setup where the migration is actually tested? I had something in mind, https://github.com/GEWIS/sudosos-backend/issues/176, but the issue was that you need a "previous" database to migrate and test from.
My suggestion, is we make a ci job that does the following:
pull and build sudosos from the target branch, sync the mariadb and then go to the source version of the PR so that we can actually migrate and test?
I think we need to make an "initial" migration to build upon. Then you can build your complete database schema by using the migrations and compare this to the result of a TypeORM synchronize. Any discrepancies you can immediately detect. However, making such an "initial" migration is going to be a huge pain...
:tada: This PR is included in version 0.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Description
Fixes two mistakes/errors in the nested product categories migration:
parentId
column in theproduct_category
table. After some thinking, this makes sense: how else would you distinguish your parents from your ancestors? Stupid me was stupid.product_category
table, the closure table should include a mapping from each record to itself. The migration did not do this (but now it does)!These two things therefore will need manual fixing in the test environment, as there already is a newer migration in the list. However, we can also undo the Stripe migration and then redo this migration as well, as the Stripe migration is not destructive.
Related issues/external references
Types of changes