- changed status to open
Django's EmailField.max_length affects Postman's Migrations
It has been quite a while since Django switched to using 254 as the default EmailField.max_length. However, Postman's initial migration (0001_initial) still has max_length=75 hardcoded in it:
('email', models.EmailField(max_length=75, verbose_name='visitor', blank=True))
Also, Postman's models.py specify no max_length for the email field. Therefore, on a fresh setup, when makemigraitons is used on any other app depending on Postman (or on all apps), then Django produces a second migration for Postman to fix this conflict:
E.g. 0002_auto_20150901_2347.py
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
class Migration(migrations.Migration):
dependencies = [
('postman', '0001_initial'),
]
operations = [
migrations.AlterField(
model_name='message',
name='email',
field=models.EmailField(max_length=254, verbose_name='visitor', blank=True),
),
]
Basically, when scanning models.py, recent versions of Django sees no max_length set for the email field, and then it falls back to max_length=254 from its own default. And then, when it compares current models.py state with 0001_initial migration, it concludes with the above migration.
It's a common practice not to include third-party apps in VCS. So, this becomes a major issue when the core app/project is forced to depend on some newly produced migration which do not exist on a fresh copy of Postman installed from PyPI.
Possible fixes:
Set max_length=75 in models.py, or best, to comply with RFCs 3696 and 5321, patch 0001_initial to have:
('email', models.EmailField(max_length=254, verbose_name='visitor', blank=True))
Comments (3)
-
repo owner -
reporter - edited description
-
repo owner - changed status to resolved
Fixed in v3.3.1 with a revised 0001_initial.py.
- Log in to comment