Tweak db prepare/migrate/seed for multiple gateways #234
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.
Fix a range of issues detected during manual testing with a (soon-to-be) 2.2.beta2 app with multiple DB gateways configured for the app:
db prepare
was failing, since the ROM/Sequel migrator needs every configured getaway to have its database created before the migrator can run. To fix this, change the order of the nesteddb prepare
commands, so thatdb create
anddb structure load
are run first for every detected database. After that is done, move ontodb migrate
for each detected database. Finally, rundb seed
.db prepare
now runs commands in a mixed order (i.e. no longer a single slice at a time), change the handling of command failures such that they halt and exit the entire command immediately. This should make it easier for the user to identify and address failures, and reduces the chance of unexpected outcomes from latter steps being impacted by earlier failures.db seed
should run only once for each slice, but our internal#databases
method will yield for each database, so when a slice has multiple gateways, we were trying to seed it multiple times. To fix this, track the seeded slices and skip seeding for subsequence detected databases if the slice has already been seeded.config/db/[gateway_name]_migrate/
). This would occur in bothdb migrate
as well asdb structure dump
(which uses the migrator to know the applied migrations to include at the bottom of the structure file). To fix these, skip attempting to load the migrator for a gateway database if there is no matching migration dir found.db prepare
from us accidentally assigning thefs
as a DB command'sinflector
.I've updated the existing
db prepare
specs to reflect this new behaviour, where applicable. We would do well to add another couple of examples for the edge cases above (e.g. missing migration dirs), but I'm going to defer those until later, so we don't delay a timely 2.2.0.beta2 release this week. See #235 as a reminder to come back and add those tests.