Opened 10 years ago

Closed 7 years ago

Last modified 7 years ago

#21498 closed Bug (invalid)

Changing locale causes migrations autodetector to make unnecesary changes

Reported by: foonicorn Owned by: Andrew Godwin
Component: Migrations Version: dev
Severity: Normal Keywords:
Cc: info@…, loic@…, andrew@…, tomas.kostrhun@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

A migration is created after fields like help_text changed, although this is not relevant for the database. This also occurs when i18n is used and the translation changes.

Change History (36)

comment:1 by Markus Holtermann, 10 years ago

Cc: info@… added
Owner: set to Markus Holtermann
Status: newassigned

comment:2 by loic84, 10 years ago

FWIW I don't think it's a good idea to start blacklisting / whitelisting parameters, especially with custom fields in mind.

in reply to:  2 comment:3 by Markus Holtermann, 10 years ago

I'm going to implement it in a way that fields can define their own non-db-relevant arguments.

comment:4 by Tim Graham, 10 years ago

Triage Stage: UnreviewedAccepted

comment:5 by loic84, 10 years ago

Cc: loic@… added

comment:6 by Andrew Godwin, 10 years ago

I'd rather we included every single field - white/blacklisting fields is dangerous. What if a field subclass redefines help_text? What if it uses it to help populate ORM objects? I'd like to mark this WONTFIX.

comment:7 by loic84, 10 years ago

+1, I'm particularly concerned by the fate of validators which were blacklisted in the tentative patch presented on IRC.

Also with the upcoming VirtualField we will be blurring the lines more and more between the ORM and the underlying schema.

However there seems to be an valid issue here, i18n locale shouldn't trip the autodetector, I haven't had time to look into it but I suspect this is due to the fix for #21008.

comment:8 by Markus Holtermann, 10 years ago

I think we should find a solution for this: imaging your translators change the translation for a help text. All the time they do one developer will end up with such a new migration.

The way I implemented it allows fields to redefine their attributes. It's a prove of concept: https://github.com/Markush2010/django/tree/ticket21498

comment:9 by Andrew Godwin, 10 years ago

I agree that the locale shouldn't trip the autodetector, but changing help_text unfortunately has to (we just can't guarantee it's not useful at database or field runtime).

Perhaps we should force a certain locale while running the autodetector?

comment:10 by Andrew Godwin, 10 years ago

Cc: andrew@… added

comment:11 by Andrew Godwin, 10 years ago

Summary: Unnecessary migrations after nonrelevat fields changedChanging locale causes migrations autodetector to make unnecesary changes

comment:12 by loic84, 10 years ago

To solve this we may need a better way to handle Promises, maybe we could make them "deconstructible"?

comment:13 by Andrew Godwin, 10 years ago

Well, the serializer currently runs any Promise through force_text before saving it, but the autodetector doesn't serialize anything before it compares. To be honest, if we could make Promises comparable (and make them evaluate on eq) that would solve it.

comment:14 by Andrew Godwin, 10 years ago

Owner: changed from Markus Holtermann to Andrew Godwin
Severity: NormalRelease blocker

Claiming this to fix it tonight, as it just got way worse now we have migrations for contrib apps (upping to release blocker due to that)

comment:15 by Andrew Godwin <andrew@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In d359647715bccffd7cfc5eb8bcf5edb5c714fb00:

Fixed #21498: Don't use a fallback language if you're en-us.

comment:16 by Andrew Godwin, 10 years ago

Oddly, no fix was needed on the stable/1.7.x branch, as it did not show the symptom in my tests; this appears to have been fixed by a the new autodetector code and then broken by https://github.com/django/django/commit/a5f6cbce07b5f3ab48d931e3fd1883c757fb9b45.

If someone can get the problem on the stable/1.7.x branch please reopen.

comment:17 by ChillarAnand, 9 years ago

Resolution: fixed
Status: closednew

comment:18 by Simon Charette, 9 years ago

Resolution: fixed
Status: newclosed

@ChillarAnand, please don't re-open without providing a valid reason.

Did you manage to reproduce the issue on the stable/1.7.x branch?

comment:19 by Tomáš KOSTRHUN, 9 years ago

I can reproduce it on 1.7.2.

Started the project with

LANGUAGE_CODE = 'cs'
LANGUAGES = ( ('cs', 'Czech'), ('en', 'English'), )
USE_I18N = True

all model fields with verbose_name in Czech like

from django.db import models
from django.utils.translation import ugettext_lazy as _

class Book(models.Model):
    name = models.CharField(_(u'Název'), max_length=255)

initial migration

('name', models.CharField(max_length=255, verbose_name='N\xe1zev')),

after I've added en locale and translated "Název" as "Title" makemigrations shows

migrations.AlterField(
    model_name='book',
    name='name',
    field=models.CharField(max_length=255, verbose_name='Title'),
    preserve_default=True,
),

when I import _ in models.py just as ugettext (not ugettext_lazy) problem disappears.

comment:20 by Tomáš KOSTRHUN, 9 years ago

Cc: tomas.kostrhun@… added

comment:21 by Tim Graham, 9 years ago

Hi Tomas, can you test with Django's master branch? I believe that issue might be related to/fixed by f7c287fca9c9e6370cc88d1457d3ed9466703687.

in reply to:  21 comment:22 by Markus Holtermann, 9 years ago

Replying to timgraham:

Hi Tomas, can you test with Django's master branch? I believe that issue might be related to/fixed by f7c287fca9c9e6370cc88d1457d3ed9466703687.

It's exactly the case I constructed in https://github.com/django/django/pull/3838#issuecomment-68784330

comment:23 by Claude Paroz, 9 years ago

In Django 1.8, you *might* obtain a new migration just after having upgraded from 1.7 (if the existing migration uses a translated string), but then the translations won't affect migrations any longer.

in reply to:  21 comment:24 by Tomáš KOSTRHUN, 9 years ago

Replying to timgraham:

Hi Tomas, can you test with Django's master branch? I believe that issue might be related to/fixed by f7c287fca9c9e6370cc88d1457d3ed9466703687.

Hello Tim, yes, django trunk shows "No changes detected" so it's OK.

comment:25 by Hedde van der Heide, 8 years ago

This issue re-occurs on 1.9.2, I managed to overcome it by overwriting the makemigrations command then forcing a default locale.. perhaps this should be a django setting anyway, optionally adding the flag through cli?

Last edited 8 years ago by Hedde van der Heide (previous) (diff)

comment:26 by Hedde van der Heide, 8 years ago

Resolution: fixed
Status: closednew

comment:27 by Claude Paroz, 8 years ago

Resolution: needsinfo
Status: newclosed

I was not able to reproduce it with Django 1.9.2. You might have to create a sample project where this can be reproduced to convince us.

in reply to:  27 comment:28 by Martin Bächtold, 7 years ago

Replying to Claude Paroz:

I was not able to reproduce it with Django 1.9.2. You might have to create a sample project where this can be reproduced to convince us.

I have create a sample project available at https://github.com/mbaechtold/django-ticket-21498-demo

Hope this helps to convince you this is still an issue.

Version 0, edited 7 years ago by Martin Bächtold (next)

comment:29 by Claude Paroz, 7 years ago

Martin, many thanks for the sample project. Could you please try to reproduce the issue by replacing ugettext by ugettext_lazy in the polls/models.py file?

comment:30 by cryptogun, 7 years ago

Same problem here. makemigrations executed from production server and local server would always generate new migration files. Not good for Git control.
App: django-avatar

diff ./avatar/migrations/0006_auto_20170329_0405.py ./avatar/migrations/0007_auto_20170329_0455.py 
2c2
< # Generated by Django 1.10.5 on 2017-03-28 20:05
---
> # Generated by Django 1.10.5 on 2017-03-28 20:55
14c14
<         ('avatar', '0005_auto_20170306_1939'),
---
>         ('avatar', '0006_auto_20170329_0405'),
20c20
<             options={'ordering': ['-pk'], 'verbose_name': 'avatar', 'verbose_name_plural': 'avatars'},
---
>             options={'ordering': ['-pk'], 'verbose_name': '头像', 'verbose_name_plural': '头像'},
25c25

...

comment:31 by Tim Graham, 7 years ago

It's a bug in django-avatar -- it uses from django.utils.translation import ugettext as _ rather than ugettext_lazy as Claude mentioned.

in reply to:  29 comment:32 by Martin Bächtold, 7 years ago

Replying to Claude Paroz:

Martin, many thanks for the sample project. Could you please try to reproduce the issue by replacing ugettext by ugettext_lazy in the polls/models.py file?

Claude, sorry for the delay, I did not get a notification about your comment.

Replacing ugettext by ugettext_lazy in the polls/models.py file did not solve the problem. New migration files are generated anyway when changing settings.LANGUAGE_CODE.

comment:33 by Martin Bächtold, 7 years ago

Resolution: needsinfo
Status: closednew

comment:34 by Claude Paroz, 7 years ago

Martin, could you then update your sample project to use ugettext_lazy?

comment:35 by Martin Bächtold, 7 years ago

Resolution: fixed
Status: newclosed

Claude, I was somewhat rash with my previous statement. I created the demo project from scratch (locally only, not pushed to GitHub) using ugettext_lazy and I could not reproduce the error. I assume this ticket can be closed. Thanks for your help!

comment:36 by Tim Graham, 7 years ago

Resolution: fixedinvalid
Severity: Release blockerNormal
Note: See TracTickets for help on using tickets.
Back to Top