Сбой Django: "DatabaseError: слишком длинное значение для символа типа (50)"

Ответ 1

Хорошо, что отличает кодирование баз данных шаблонов. На производственном сервере у них была кодировка ascii, а в dev-dev - utf-8.

По умолчанию postgres создает базу данных с помощью шаблона1. Я понимаю, что если его кодировка не является utf-8, то создаваемая вами база данных будет иметь эту проблему, даже если вы создадите ее с помощью кодировки utf-8.

Поэтому я бросил его и воссоздал его с его кодировкой, установленной в UTF8. Ниже приведен фрагмент ниже (взято из здесь):

psql -U postgres 

UPDATE pg_database SET datallowconn = TRUE where datname = 'template0';
\c template0
UPDATE pg_database SET datistemplate = FALSE where datname = 'template1';
drop database template1;
create database template1 with template = template0 encoding = 'UNICODE';
UPDATE pg_database SET datistemplate = TRUE where datname = 'template1';
\c template1
UPDATE pg_database SET datallowconn = FALSE where datname = 'template0';

Теперь светильник загружается плавно.

Ответ 2

Обновление: ограничение 50 char теперь 255 в Django 1.8

-

Оригинальный ответ:

Я просто столкнулся с этим сегодня днем, и у меня есть исправление.

Этот пост здесь подразумевал ошибку Django, связанную с длиной значения, разрешенного для auth_permission. Дальнейшее копирование поддерживает эту идею, так же как этот Django-билет (хотя он первоначально связан с MySQL).

В основном, что имя разрешения создается на основе verbose_name модели плюс описательная строка разрешений и может переполняться до более чем 50 символов, разрешенных в auth.models.Permission.name.

Чтобы процитировать комментарий к билету Django:

Самые длинные префиксы для строкового значения в столбце auth_permission.name: "Can change" и "Can delete", как с 11 символами. Максимальная длина столбца равна 50, поэтому максимальная длина Met.verbose_name равна 39.

Одним из решений было бы взломать этот столбец, чтобы он поддерживал > 50 символов (в идеале, через южную миграцию, я говорю, чтобы он легко воспроизводился), но самое быстрое и надежное исправление, о котором я мог думать, long verbose_name определение намного короче (от 47 символов в verbose_name до около 20). Все работает отлично.

Ответ 3

Получите реальный SQL-запрос в обеих системах и посмотрите, что другое.

Ответ 4

Только для информации: у меня также была эта ошибка

DatabaseError: value too long for type character varying(10)

Кажется, что я писал данные за лимит в 10 для поля. Я исправил его, увеличив размер CharField от 10 до 20

Я надеюсь, что это поможет

Ответ 5

Как говорит @stevejalim, вполне возможно, что столбец auth_permission.name является проблемой с длиной 50, вы проверяете это с помощью \d + auth_permission в оболочке postgres. В моем случае это проблема, поэтому, когда я загружаю модели django, я получил "DatabaseError: слишком длинное значение для переменной типа (50)", затем измените django.contrib.auth. Модель разрешения сложна, поэтому... простая решение выполнило миграцию на модели Permission, я выполнил эту команду ALTER TABLE auth_permission ALTER COLUMN name TYPE VARCHAR(100); в оболочке postgres, это работает для меня.

кредиты для этого комментария

Ответ 6

Вы можете заставить Django использовать более длинные поля для этой модели, обезглавливая модель до использования ее для создания таблиц базы данных. В "manage.py" измените:

if __name__ == "__main__":
    execute_manager(settings)

в

from django.contrib.auth.models import Permission
if __name__ == "__main__":
    # Patch the field width to allow for our long model names
    Permission._meta.get_field('name').max_length=200
    Permission._meta.get_field('codename').max_length=200
    execute_manager(settings)

Это изменяет параметры в поле до (скажем) manage.py syncdb, поэтому таблица данных имеет хорошие широкие поля varchar(). Вам не нужно делать это при вызове вашего приложения, так как вы никогда не пытаетесь изменить таблицу разрешений на использование.