Better make test-schema - #428
Conversation
…o test db for 'make test-schema'
| command = os.Args[1] | ||
| } | ||
|
|
||
| if !config.Cfg.RunMigrations && command != "migrate" { |
There was a problem hiding this comment.
i'd prefer this be wet and still called inside each switch. someone adding a switch in the future may accidentally wreck a db not knowing this auto runs
There was a problem hiding this comment.
after thinking about it some more, i feel like this might be a non-issue or at least quite a rare occurrence. for it to be a problem, you'd have to:
- Be connected to an existing db, like prod/stage
- Have
runMigrations=true - Have a new command you're adding
- Have a bad new migration that does something you don't want to do on those dbs
I think it's probably easier to reason around having any command will run migrations if runMigrations=true vs all the special casing
There was a problem hiding this comment.
Do we actually want every command to run migrations though? It means when we deploy, every container in every replica tries to grab the lock to run the migrations, when we only need one of them to do it. Just seems like a lot more thrash for the benefit of only tests.
There was a problem hiding this comment.
this is equivalent to what it was before, besides elasticsearch. It makes a lot of sense for the dev flow, but I agree is a bit overkill for deploys. We could pick a single command to champion migrations but I think it's alright for now
| command = os.Args[1] | ||
| } | ||
|
|
||
| if !config.Cfg.RunMigrations && command != "migrate" { |
There was a problem hiding this comment.
Do we actually want every command to run migrations though? It means when we deploy, every container in every replica tries to grab the lock to run the migrations, when we only need one of them to do it. Just seems like a lot more thrash for the benefit of only tests.
make test-schemamake migrate