Run db commands on test as well as development databases #247
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's a frustrating experience if users have to remember to run each of their
hanami db
commands again with-e test
after running them on their development database.To improve this, update a number of commands to automatically re-run on the test database after completing their work on the development database:
db create
db drop
db migrate
db prepare
db structure load
The re-run on test will only take place if these commands operate with the development environment. Running the commands in other environments (e.g. production or test) will run on the database in those environments only.
To achieve this "re-run on test" behaviour, at the end of these
db
commands, we invoke another process to call the relevanthanami db
command again, but with theHANAMI_ENV=test
environment variable set. For this re-run, all given CLI flags are preserved, but-e
and--env
are of course stripped.The reason we have to take this approach is because right now there's no straightforward way to re-boot the Hanami app in a different environment, or stand up the database subsystem itself in a different environment.
I'd like to for us to make one of these possible (certainly the latter feels reasonable) in the future, but to make the user experience as good as possible for 2.2, we're taking a pragmatic approach here.
Resolves #215