If you add CREATE_TABLES = 1 to the .env on the dashboard, it causes the schema to be re-read from the pipeline, and all the tables get rebuilt.
BUT keeping that flag set to '1' causes the tables to ALWAYS be rebuilt, which is a huge performance hit.
SO when a schema change is part of a release, the Release Engineer needs to:
1) set the CREATE_TABLES=1 in the .env and reset the database by clicking 'sync' in the 'Danger Zone' on the dashboard.
2) set the CREATE_TABLES=0 in the .env after the sync is done, which will be a very long time, to avoid performance problems
By assigning Dawn, I'm hoping she can track until we can staff these kinds of issues.
If you add CREATE_TABLES = 1 to the .env on the dashboard, it causes the schema to be re-read from the pipeline, and all the tables get rebuilt. BUT keeping that flag set to '1' causes the tables to ALWAYS be rebuilt, which is a huge performance hit. SO when a schema change is part of a release, the Release Engineer needs to: 1) set the CREATE_TABLES=1 in the .env and reset the database by clicking 'sync' in the 'Danger Zone' on the dashboard. 2) set the CREATE_TABLES=0 in the .env after the sync is done, which will be a very long time, to avoid performance problems
By assigning Dawn, I'm hoping she can track until we can staff these kinds of issues.
Close this ticket when: