Migration from globalize: foreign keys

[Splines]

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 MaMpf-HD/mampf#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 MaMpf-HD/mampf#655):

• Foreign key constraints were added, which is probably due to Table-backend migration generator creates wrong migrations #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.

[shioyama]

I'm not really sure what happened there, but you have to include --backend table when running migrations, otherwise it will default to Mobility.default_backend which would be key_value. You should never need to have the translation attributes on the model table (except with the Column backend, in which case they are like name_en, name_ja etc).

[shioyama]

I'm closing this since it's not clear how to proceed here. These things are well-documented in tests, if something isn't working then isolate the problem and make a PR with a fix, or one with a test that is failing on the bug.

[shioyama]

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.

No, definitely not, you shouldn't need them. If they were added by Mobility that could be a bug, but if so I've never heard of it.