Migrate to supporting database v133 with table removals #983
Conversation
|
Is it normal for the docker pulls to randomly fail? Or is there some issue with the github network? Edit; Docker Hub is having issues |
|
Just to stress out the importance of the topic: v130 was supposed to delete the tables in question (along with others) which caused user fail to login, which fall back to loading of the old ratings. And there were maaany, so we actually had to rollback the db to v129 on prod. So this is a priority or we need to remove all migrations and redo them, which i'd like to avoid. |
|
There was no functionality that was reliant on these tables so was a simple removal. So I am just waiting on @Askaholic to give it the final sign off. But it doesn't interact with the message protocol at all |
|
Sorry, I was traveling today. I won’t get to it until tomorrow at the earliest. |
|
No merge commit please, we can squash even if the branch is technically out of date so long as there are no conflicts. Or rebase. |
|
I guess it doesn't matter. I can just delete the merge commit from the squashed commit message |
|
I was expecting the update branch button to rebase -_- |
Sheikah45
force-pushed
the
maintenance/db-v133
branch
from
33e7560
to
37434b7
Compare
|
And I ran the server locally and it worked |
|
Apparently you can actually do this now, but you have to select it from the dropdown menu: https://stackoverflow.com/questions/69839124/update-branch-with-rebase-instead-of-merge |
|
Yeah I am just used to gitlab now where rebase is the default |
No description provided.