zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-06-29 07:43:32 +02:00
Code Issues Projects Releases Packages Wiki Activity

Update migration-troubleshooting.md

Browse source
This commit is contained in:
zandercymatics 2023-12-04 15:28:34 -07:00
parent e100a0edbd
commit 7bc77ac4f9
No known key found for this signature in database
GPG key ID: FF4636ABEC9682B7
1 changed files with 0 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

9
docs/developer/migration-troubleshooting.md
View file

@ -13,12 +13,6 @@ Some common commands:
- ./manage.py showmigrations -- the migration changes should now have a [x] by it - ./manage.py showmigrations -- the migration changes should now have a [x] by it
On occasion, you will need to run this set of commands to refresh your environment:
- docker-compose down
- docker-compose build
- docker-compose up
## Scenarios ## Scenarios
### Scenario 1: Conflicting migrations on local ### Scenario 1: Conflicting migrations on local
@ -60,7 +54,6 @@ This has happened when updating user perms (so running a new data migration). So
- `cf run-task getgov-<app> --wait --command 'python manage.py migrate registrar 39_penultimate_miration --fake' --name migrate` - `cf run-task getgov-<app> --wait --command 'python manage.py migrate registrar 39_penultimate_miration --fake' --name migrate`
- `cf run-task getgov-<app> --wait --command 'python manage.py migrate' --name migrate` - `cf run-task getgov-<app> --wait --command 'python manage.py migrate' --name migrate`
### Scenario 4: All migrations refuse to load due to existing duplicates on sandboxes ### Scenario 4: All migrations refuse to load due to existing duplicates on sandboxes
This typically happens with a DB conflict that prevents 001_initial from loading. For instance, let's say all migrations have ran successfully before, and a zero command is ran to reset everything. This can lead to a catastrophic issue with your postgres database. This typically happens with a DB conflict that prevents 001_initial from loading. For instance, let's say all migrations have ran successfully before, and a zero command is ran to reset everything. This can lead to a catastrophic issue with your postgres database.
@ -83,7 +76,6 @@ Afterwards, go back to your psql instance. Run the following for each problemati
Then, run `./manage.py migrate` again and repeat step 7 for each table which returns this error. Then, run `./manage.py migrate` again and repeat step 7 for each table which returns this error.
After these errors are resolved, follow instructions in the other scenarios if applicable. After these errors are resolved, follow instructions in the other scenarios if applicable.
### Scenario 5: Permissions group exist, but my users cannot log onto the sandbox ### Scenario 5: Permissions group exist, but my users cannot log onto the sandbox
This is most likely due to fixtures not running or fixtures running before the data creating migration. Simple run fixtures again (WARNING: This applies to dev sandboxes only. We never want to rerun fixtures on a stable environment) This is most likely due to fixtures not running or fixtures running before the data creating migration. Simple run fixtures again (WARNING: This applies to dev sandboxes only. We never want to rerun fixtures on a stable environment)
@ -105,7 +97,6 @@ Example: there are extra columns created on a table by an old migration long sin
- `SELECT * FROM {bad_table};` - `SELECT * FROM {bad_table};`
- `alter table registrar_domain drop {bad_column};` - `alter table registrar_domain drop {bad_column};`
### Scenario 7: Continual 500 error for the registrar + your requests (login, clicking around, etc) are not showing up in the logstream ### Scenario 7: Continual 500 error for the registrar + your requests (login, clicking around, etc) are not showing up in the logstream
Example: You are able to log in and access the /admin page, but when you arrive at the registrar you keep getting 500 errors and your log-ins any API calls you make via the UI does not show up in the log stream. And you feel like you’re starting to lose your marbles. Example: You are able to log in and access the /admin page, but when you arrive at the registrar you keep getting 500 errors and your log-ins any API calls you make via the UI does not show up in the log stream. And you feel like you’re starting to lose your marbles.