Setting user_related_name results in strange migrations in v2.6.0

[dgilge]

Describe the bug

1. Setting user_related_name="mymodels" doesn't change related_name="+" to related_name="mymodels" since v2.6.0.
2. Setting user_related_name="mymodels" shouldn't alter other values in migrations

To Reproduce

1. Install v2.5.1
2. Add a history to a model, e.g. with register:

register(
    EmailAddress,
    app=__package__,
    excluded_fields=('primary',),
    user_related_name='historicalemailaddresses',
)

3. Run makemigrations
4. Install v2.6.0
5. Run makemigrations
6. Remove user_related_name
7. Run makemigrations

Expected behavior

1. No. 5 shouldn't create another migration with related_name="+"
2. No. 7 should change related_name="+" only (but it doesn't because it has this value in the previous migration already). But the change looks like this on my system:

After applying No. 5:

        migrations.AlterField(
            model_name="historicalemailaddress",
            name="user",
            field=models.ForeignKey(
                blank=True,
                db_constraint=False,
                null=True,
                on_delete=django.db.models.deletion.DO_NOTHING,
                related_name="+",
                to=settings.AUTH_USER_MODEL,
                verbose_name="user",
            ),
        )

Why were blank, db_constraint and verbose_name (and other values like help_text in other cases) added here?

After applying No. 7:

        migrations.AlterField(
            model_name="historicalemailaddress",
            name="history_user",
            field=models.ForeignKey(
                null=True,
                on_delete=django.db.models.deletion.SET_NULL,
                related_name="+",
                to=settings.AUTH_USER_MODEL,
            ),
        )

The migration in < v2.6.0 looked like (I comment strange changes):

        migrations.AlterField(
            model_name="historicalemailaddress",
            name="history_user",  # Why this changed to "user"?
            field=models.ForeignKey(
                null=True,
                on_delete=django.db.models.deletion.SET_NULL,  # Why this changed to "DO_NOTHING"?
                related_name="historicalemailaddresses",
                to=settings.AUTH_USER_MODEL,
            ),
        )

Environment:

• OS: macOS 10.13.6
• Django Simple History Version: 2.6.0, 2.7.0
• Django Version: 2.0.10
• Database Version: PostgreSQL 9.6

I also want to say "thank you" for all the improvements and fixes you implemented in the last months for simple history and for keeping this package alive!

[rossmechanic]

Hey @dgilge thanks for noticing all of the hard work we've been putting into this package over the past 10 months! We also want to thank you for your continued contributions to the repo.

The migrations that you're seeing here are expected and shouldn't change functionality. We probably could have done a better job of explaining this in the changelog though. As of #462, we now respect the deconstruct method on ForeignKey's which allows users to write custom foreign keys. As a result, all of the fields from your base models foreign key will be passed to the equivalent historical model. However, to make history work, some of those are overwritten (as they were before), such as db_constraint (which should always be false... we don't want db constraints on historical models) and related_name (which for a foreign key on the history model should always be '+'). Some of the fields that will pass through to your history model (and thus create migrations that don't actually affect the database) now are verbose_name, help_text, auto_created. IMO, this makes more sense than the previous implementation as your history fields more similarly mimic your base fields (and the necessary fields are overwritten).

My guess is that the model itself has user on it, correct? That would explain the migration. If I'm correct, all of your weird migrations should be due to what I described above, and user_related_name should still function as expected. Let me know if I missed something though.

Again, thank you for using this project and giving back to the community by raising issues and PRs!

[dgilge]

Thank you for your detailed answer! Your explanation seems to be correct and would explain why all of my tests still pass. So, there was just coming too much together I couldn't explain myself…

My guess is that the model itself has user on it, correct?

That's correct. I didn't recognize that user and history_user are just two different fields. 🤦🏻‍♂️

We probably could have done a better job of explaining this in the changelog though.

My suggestion was to add an information somewhere (probably in the changelog) that other users know that they should run makemigrations after updating to v2.6+ and that the migrations shouldn't change the functionality. (I was a little surprised when our frontend developer told me that I forgot to create a migration.)

I'm happy that I don't have to pin this package to v2.5.1! Thanks for your great support!

[rossmechanic]

Sorry for the confusion! Going to close this issue and make sure I include documentation on these migrations in the next maintenance release.