mobility icon indicating copy to clipboard operation
mobility copied to clipboard

Migration from `globalize`: foreign keys

Open Splines opened this issue 8 months ago • 0 comments

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 table subjects, programs and divisions. 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.

Splines avatar Jul 01 '24 17:07 Splines