Приспособление Django завершается неудачно, сообщая: «DatabaseError: значение слишком длинное для изменения типа символа (50)»

Question

У меня есть прибор (json), который загружается в среде разработки, но не в состоянии в серверной среде.В сообщении об ошибке говорится: «DatabaseError: value too long for type character varying(50)»

Моя среда разработки - Windows & Postgres 8.4.Сервер работает Debian и Postgres 8.3.Кодировка базы данных - UTF8 в обеих системах.

Как будто маркеры юникода в приборе считаются как символы на сервере, и они заставляют некоторые строки превышать максимальную длину их поля.Однако этого не происходит в среде разработчиков.

Answer 1

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

-

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

Я только что столкнулся с этим днемИ у меня тоже есть исправление (вроде)

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

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

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

Самые длинные префиксы для строкового значения в столбце auth_permission.name - «Можно изменить» и «Можно удалить», оба из 11 символов.Максимальная длина столбца равна 50, поэтому максимальная длина Meta.verbose_name равна 39.

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

Answer 2

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

По умолчанию postgres создает базу данных, используя template1.Насколько я понимаю, если его кодировка не является 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';

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

Answer 3

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

Answer 4

Вы можете заставить 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 ().Вам не нужно делать это при вызове приложения, так как вы никогда не пытаетесь изменить таблицу прав доступа при запуске.

Answer 5

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

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

Answer 6

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

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

Похоже, я записывал данные в поле, превышающее 10 для поля. Я исправил это, увеличив размер CharField с 10 до 20

Надеюсь, это поможет