Django не может определиться с валидацией username
1,00
р.
Суть: в Django 1.10 завезли поддержку юникода в юзернеймах.
Нюанс: она по умолчанию включена только для Python 3, а для Python 2 по-прежнему только ASCII.
Проблема: я пишу сайт для обоих питонах сразу (на 1.11 обновиться до 2.1, понятно, не могу) и периодически работаю то там, то тут. Когда я создаю миграцию в третьем питоне, джанга так и норовит создать бессмысленное изменение, меняющее валидатор на юникодный:
class Migration(migrations.Migration): # ... operations = [ # ... migrations.AlterField( model_name='user', name='username', field=models.CharField(error_messages={'unique': 'A user with that username already exists.'}, help_text='Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only.', max_length=150, unique=True, validators=[django.contrib.auth.validators.UnicodeUsernameValidator()], verbose_name='username'), ), ]
После применения этой миграции, если я создам новую миграцию уже во втором питоне — наоборот, джанга стремится всё откатить и вернуть ASCII обратно:
class Migration(migrations.Migration): # ... operations = [ # ... migrations.AlterField( model_name='user', name='username', field=models.CharField(error_messages={'unique': 'A user with that username already exists.'}, help_text='Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only.', max_length=150, unique=True, validators=[django.contrib.auth.validators.ASCIIUsernameValidator()], verbose_name='username'), ), ]
(играем в игру «найди одно отличие» :)
Я попытался явно прописать конкретный валидатор по образу и подобию совета из документации:
from django.utils.encoding import python_2_unicode_compatible from django.contrib.auth.models import AbstractUser from django.contrib.auth.validators import ASCIIUsernameValidator
@python_2_unicode_compatible class User(AbstractUser): username_validator = ASCIIUsernameValidator() # ...и всякие остальные поля
...но не изменилось абсолютно ничего: создание миграции в третьем питоне по-прежнему старательно пихает UnicodeUsernameValidator куда не надо, во втором питоне соответственно наоборот.
Как усмирить джангу и заставить использовать что-то одно на всех питонах, если совет из документации не работает?
Неужто копипастить поле username из исходников AbstractUser себе целиком? А поадекватнее способа не найдётся?
Ответ
На ваш вопрос (что делать?) я не отвечу, но проиллюстрирую проблему простым примером:
class A: some_class_field = 'A field' swag_field_created_on_import_time = some_class_field
def printer(self): print(self.swag_field_created_on_import_time)
class B(A): some_class_field = 'B field'
B().printer() >>> A field
В исходниках происходит то же самое: https://github.com/django/django/blobtable/1.11.x/django/contrib/auth/models.py#L308, только username_validators - это some_class_field, а сам username - это тоже классовый аттрибут, который создаётся во время импорта, и когда вы переопределяете этот аттрибут в своей кастомной модели, то это уже поздно полюбас - материнский класс создан, и все его классовые аттрибуты уже установлены
Как решение можно обмазываться метаклассами, который обновит свойство материнского класса из дочернего, или копипастить поле целиком
Нюанс: она по умолчанию включена только для Python 3, а для Python 2 по-прежнему только ASCII.
Проблема: я пишу сайт для обоих питонах сразу (на 1.11 обновиться до 2.1, понятно, не могу) и периодически работаю то там, то тут. Когда я создаю миграцию в третьем питоне, джанга так и норовит создать бессмысленное изменение, меняющее валидатор на юникодный:
class Migration(migrations.Migration): # ... operations = [ # ... migrations.AlterField( model_name='user', name='username', field=models.CharField(error_messages={'unique': 'A user with that username already exists.'}, help_text='Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only.', max_length=150, unique=True, validators=[django.contrib.auth.validators.UnicodeUsernameValidator()], verbose_name='username'), ), ]
После применения этой миграции, если я создам новую миграцию уже во втором питоне — наоборот, джанга стремится всё откатить и вернуть ASCII обратно:
class Migration(migrations.Migration): # ... operations = [ # ... migrations.AlterField( model_name='user', name='username', field=models.CharField(error_messages={'unique': 'A user with that username already exists.'}, help_text='Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only.', max_length=150, unique=True, validators=[django.contrib.auth.validators.ASCIIUsernameValidator()], verbose_name='username'), ), ]
(играем в игру «найди одно отличие» :)
Я попытался явно прописать конкретный валидатор по образу и подобию совета из документации:
from django.utils.encoding import python_2_unicode_compatible from django.contrib.auth.models import AbstractUser from django.contrib.auth.validators import ASCIIUsernameValidator
@python_2_unicode_compatible class User(AbstractUser): username_validator = ASCIIUsernameValidator() # ...и всякие остальные поля
...но не изменилось абсолютно ничего: создание миграции в третьем питоне по-прежнему старательно пихает UnicodeUsernameValidator куда не надо, во втором питоне соответственно наоборот.
Как усмирить джангу и заставить использовать что-то одно на всех питонах, если совет из документации не работает?
Неужто копипастить поле username из исходников AbstractUser себе целиком? А поадекватнее способа не найдётся?
Ответ
На ваш вопрос (что делать?) я не отвечу, но проиллюстрирую проблему простым примером:
class A: some_class_field = 'A field' swag_field_created_on_import_time = some_class_field
def printer(self): print(self.swag_field_created_on_import_time)
class B(A): some_class_field = 'B field'
B().printer() >>> A field
В исходниках происходит то же самое: https://github.com/django/django/blobtable/1.11.x/django/contrib/auth/models.py#L308, только username_validators - это some_class_field, а сам username - это тоже классовый аттрибут, который создаётся во время импорта, и когда вы переопределяете этот аттрибут в своей кастомной модели, то это уже поздно полюбас - материнский класс создан, и все его классовые аттрибуты уже установлены
Как решение можно обмазываться метаклассами, который обновит свойство материнского класса из дочернего, или копипастить поле целиком
