У меня есть веб-сайт Django под управлением mini CMS, который мы построили внутри лет назад, он использует postgresql. При сохранении простого заголовка и абзаца текста я получаю следующую ошибку:
value too long for type character varying(100)
странно то, что ни один столбец не меняется(100), они все 200 или 250, даже по умолчанию Django были изменены с 100 на 200 из-за повторно открытый билет, упомянутый здесь
кто-нибудь знает решение этой проблемы?
7 ответов
Я могу поспорить, что у вас есть SlugField без предопределенной длины? Установите значение 255 и перенесите
52
автор: Michael Samoylov
это сообщение об ошибке от Postgres, а не django.
вы, похоже, изменили длину поля в models.py, но это не меняет длину базы данных, которая была создана, когда вы сделали manage.py syncdb.
вы должны изменить длину поля в базе данных, напрямую.
13
автор: Lakshman Prasad
Михаил Самойловответ указал мне в правильном направлении. У меня была такая же ошибка, за исключением того, что это было с FileField.
поля имеют max_length, даже если вы явно не установили max_length. Увеличьте значение, чтобы ваши данные соответствовали, чтобы избежать ошибки.
в моем случае данные были слишком большими для разумного хранения в базе данных. Я решил сохранить файл на диск, а затем сохранить путь к файлу в базе данных.
Я понимаю, что вопрос уже ответил, но для других, которые приходят сюда при поиске сообщения об ошибке:
в моем случае проблема заключалась в том, что мое имя таблицы превышало 50 символов. Очевидно, это запрещено. Изменение имени таблицы решило проблему.
подробнее здесь:https://code.djangoproject.com/ticket/18959
у меня была аналогичная проблема с django-autoslugfield
Я использовал аналогичный пакет, а затем переключился на django-autoslugfield
я получал эту ошибку:
value too long for type character varying(50)
несмотря на то, что мой models.py было:
slug = AutoSlugField(max_length=255, populate_from='name', unique=True)
и в моей БД это типа был
character varying 255
как только я удалю max_length=255 С поля, т. е.
slug = AutoSlugField(populate_from='name', unique=True)
затем он работал нормально
Если вы используете Django, и ничего из этого не работает. попробуйте удалить все файлы миграции и снова запустить
python manage.py makemigrations
затем
python manage.py migrate
Подключил к проекту базу postgres, провел все миграции, они применились, в моделях нигде нет ограничения в 300 символов, но вылетает эта ошибка. Причем в базе все сохраняется, после того как вылетает ошибка, перезагружаю страницу и значение сохраняется, в самой базе тоже нет никаких ошибок при добавлении напрямую, ограничений на 300 символов тоже нет. Раз дело не в базе, то в чем? Может я не так провел миграции? Но они применились правильно, я удалял их, удалял базу, пересоздавал базу заново, менял кодировки, но все в бестолку, миграции применяются, но ошибка продолжает вылетать. Может это проблема ORM? Подскажите пожалуйста где может быть проблема и что я делаю не так.
Traceback:
Environment:
Request Method: POST
Request URL: http://192.168.10.222:8080/base/edit_project/1099/
Django Version: 2.2
Python Version: 3.8.7
Installed Applications:
['django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'templatesApp',
'changelog',
'accounts',
'dashboard',
'reference',
'baseTables',
'adminTables',
'reports']
Installed Middleware:
['django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware']
Traceback:
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py" in _execute
84. return self.cursor.execute(sql, params)
The above exception (value too long for type character varying(300)
) was the direct cause of the following exception:
File "/usr/local/lib/python3.8/dist-packages/django/core/handlers/exception.py" in inner
34. response = get_response(request)
File "/usr/local/lib/python3.8/dist-packages/django/core/handlers/base.py" in _get_response
115. response = self.process_exception_by_middleware(e, request)
File "/usr/local/lib/python3.8/dist-packages/django/core/handlers/base.py" in _get_response
113. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/local/lib/python3.8/dist-packages/django/contrib/auth/decorators.py" in _wrapped_view
21. return view_func(request, *args, **kwargs)
File "/home/itpw/project/nik/vkmtsup_django2/vkmt_sup/baseTables/views.py" in EditProjectView
613. obj.save()
File "/usr/local/lib/python3.8/dist-packages/django/db/models/base.py" in save
740. self.save_base(using=using, force_insert=force_insert,
File "/usr/local/lib/python3.8/dist-packages/django/db/models/base.py" in save_base
788. post_save.send(
File "/usr/local/lib/python3.8/dist-packages/django/dispatch/dispatcher.py" in send
173. return [
File "/usr/local/lib/python3.8/dist-packages/django/dispatch/dispatcher.py" in <listcomp>
174. (receiver, receiver(signal=self, sender=sender, **named))
File "/home/itpw/project/nik/vkmtsup_django2/vkmt_sup/changelog/signals.py" in journal_save_handler
19. ChangeLog.add(instance, loggedIn.current_user, loggedIn.address, ACTION_UPDATE, (instance._meta.get_field(change).verbose_name.title()+': '+str(changed[change]['old'])+' --> ' +str(changed[change]['new'])), id=last_saved['id'])
File "/home/itpw/project/nik/vkmtsup_django2/vkmt_sup/changelog/models.py" in add
47. log.save()
File "/usr/local/lib/python3.8/dist-packages/django/db/models/base.py" in save
740. self.save_base(using=using, force_insert=force_insert,
File "/usr/local/lib/python3.8/dist-packages/django/db/models/base.py" in save_base
777. updated = self._save_table(
File "/usr/local/lib/python3.8/dist-packages/django/db/models/base.py" in _save_table
870. result = self._do_insert(cls._base_manager, using, fields, update_pk, raw)
File "/usr/local/lib/python3.8/dist-packages/django/db/models/base.py" in _do_insert
907. return manager._insert([self], fields=fields, return_id=update_pk,
File "/usr/local/lib/python3.8/dist-packages/django/db/models/manager.py" in manager_method
82. return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.8/dist-packages/django/db/models/query.py" in _insert
1186. return query.get_compiler(using=using).execute_sql(return_id)
File "/usr/local/lib/python3.8/dist-packages/django/db/models/sql/compiler.py" in execute_sql
1332. cursor.execute(sql, params)
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py" in execute
99. return super().execute(sql, params)
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py" in execute
67. return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py" in _execute_with_wrappers
76. return executor(sql, params, many, context)
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py" in _execute
84. return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.8/dist-packages/django/db/utils.py" in __exit__
89. raise dj_exc_value.with_traceback(traceback) from exc_value
File "/usr/local/lib/python3.8/dist-packages/django/db/backends/utils.py" in _execute
84. return self.cursor.execute(sql, params)
Exception Type: DataError at /base/edit_project/1099/
Exception Value: value too long for type character varying(300)Я использую spring-boot и JPA это поле, которое я использую для списка
@ElementCollection
@Column(columnDefinition="TEXT")
@CollectionTable(name="general_values")
private List<String> values;
Но я получаю ошибку
Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(255)
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2440) ~[postgresql-42.2.5.jar:42.2.5]
Однако в таблице базы данных тип value отображается как текст. Поскольку я использую TEXT в качестве типа и в столбце таблицы, он отображается как text, но ошибка по-прежнему varying(255).
И полезная нагрузка запроса для поля значения
"values":["45","There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable. If you are going to use a passage of Lorem Ipsum, you need to be sure there isn't anything embarrassing hidden in the middle of text. All the Lorem Ipsum generators on the Internet tend to repeat predefined chunks as necessary, making this the first true generator on the Internet. It uses a dictionary of over 200 Latin words, combined with a handful of model sentence structures, to generate Lorem Ipsum which looks reasonable"]
3 ответа
По умолчанию максимальное количество символов, которое вы можете сохранить, составляет 255. Попробуйте это.
@ElementCollection
@Column(columnDefinition="TEXT", length = 2048)
@CollectionTable(name="general_values")
private List<String> values;
0
Navneet Singh
13 Янв 2022 в 13:51
Во-первых, вам нужно удалить таблицу, а затем добавить атрибут длины в столбец, после чего только вы сможете увидеть эффект.
@ElementCollection
@Column(columnDefinition="TEXT", length = 1000)
@CollectionTable(name="general_values")
private List<String> values;
Или же вы можете использовать команду SQL для изменения длины
ALTER TABLE table_name MODIFY column_name varchar(new_length);
0
poorwa kesharwani
13 Янв 2022 в 15:16
Чтобы устранить эту ошибку, вам нужно либо снова создать схему, где @Column содержит свойство длины, либо вы можете вручную обновить таблицу в базе данных.
@Column(columnDefinition="TEXT", length = 1000)
private List<String> values;
При создании схемы будет создан столбец размером 1000 символов. На существующую таблицу это никак не повлияет.
0
user10260739user10260739
13 Янв 2022 в 15:19
Платные услуги для вашего проекта
- Консалтинг и техническая поддержка
Запросы в рамках коммерческой поддержки имеют гарантированное время ответа
- Разработка на заказ
Предоставляем разработку полностью нашими рабочими ресурсами или участвуем в создании вашего проекта
- Обучение
Для быстрого и всестороннего освоения особенностей платформы, чтобы повысить продуктивность вашей команды
Haulmont
мы разрабатываем современные корпоративные решения
-
Эксперты в области разработки корпоративного ПО
-
Создатели CUBA Platform
-
Компания основана в 2008
-
300+
разработчиков
-
400+
проектов
-
Клиенты в
60+
странах
У меня есть приспособление (json), которое загружается в среду разработки, но не работает в среде сервера. Ошибка говорит: «DatabaseError: value too long for type character varying(50)»
Моя среда разработки — Windows и Postgres 8.4. На сервере запущены Debian и Postgres 8.3. Кодирование базы данных — это UTF8 в обеих системах.
Как будто маркеры unicode в приборе считаются символами на сервере, и они приводят к тому, что некоторые строки превышают максимальную длину поля. Однако этого не происходит в среде dev.
Ответ 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(). Вам не нужно делать это при вызове вашего приложения, так как вы никогда не пытаетесь изменить таблицу разрешений на использование.