mobility
mobility copied to clipboard
Migration from `globalize`: foreign keys
Context
At MaMpf, we migrated from globalize
to mobility
. Everything worked flawlessly with the help of your migration guide.
Recently, we noticed that we had a few migrations using the create_translation_table!
method only provided by globalize
. We noticed this since we setup our dev environment by running through every migration starting from an empty database. We only recently discovered rails db:schema:load
which we will make use of in the future to avoid these problems where migrations cannot run through anymore as they use outdated code.
Just for testing purposes, in https://github.com/MaMpf-HD/mampf/pull/654, we deleted those non-working migrations and completely setup the database again by deleting it entirely (also its schema), then running through all migrations. After that, we used the generator provided by mobility
to generate the respective translation tables again:
rails generate mobility:translations subject name:text
rails generate mobility:translations program name:text
rails generate mobility:translations division name:text
Expected Behavior
We expected the schema.rb
to only differ in minor details.
Actual Behavior
However, if you look at the diff, we made the following observations (also described in https://github.com/MaMpf-HD/mampf/pull/655):
- Foreign key constraints were added, which is probably due to https://github.com/shioyama/mobility/issues/281 and the respective PR. -> Does this mean that these foreign keys are important? Should we add them manually via another migration? However, this was not documented in your migration guide.
- ⚠ The field
t.text "name"
was added to the tablesubjects
,programs
anddivisions
. However, this field already exists in the respective translation tables, so we don't know why we would need it in the associated table as well. ->mobility
has been working fine for us during the last few months even without these fields. Should we add them via another migration? However, this was not documented in your migration guide.
Possible Fix
Add the changes from the schema.rb
diff manually by means of new migrations.