I have a Django web site running a mini CMS we’ve built internally years ago, it’s using postgresql. When saving a simple title and a paragraph of text I get the following error:
value too long for type character varying(100)
The weird thing is, not a single column is varying(100) they are all 200 or 250, even the default Django ones have been changed from the 100 to 200 due to a re-opened ticket mentioned here
Does anyone know of a solution to this problem?
asked Jan 27, 2012 at 15:52
jeffcijeffci
2,5096 gold badges35 silver badges57 bronze badges
I can bet money you have a models.SlugField without length set. The default length is 50 characters, most likely it’s not enough for your use case.
Change it to models.SlugField(max_length=255) and migrate your database schema.
answered Jan 27, 2012 at 18:48
Michael SamoylovMichael Samoylov
2,9133 gold badges25 silver badges33 bronze badges
9
This is an error message from Postgres and not django.
You seem to have changed the length of the field in the models.py, but that doesn’t change the database length which was created when you did a manage.py syncdb.
You have to alter the length of the field in the database, directly.
answered Jan 27, 2012 at 16:00
lprsdlprsd
84k47 gold badges135 silver badges168 bronze badges
1
Django 2.1
I encountered this problem while switching from sqlite3 to postgresql.
Remove the migration files in each app’s migrations folder except __init__.py
Then re-run migration
(venv)myapp$python manage.py makemigrations
(venv)myapp$python manage.py migrate
(venv)myapp$python manage.py runserver
answered Dec 31, 2018 at 21:36
7guyo7guyo
2,9191 gold badge29 silver badges31 bronze badges
1
I had a similar problem with django-autoslugfield
I was using a similar package and then switched over to django-autoslugfield
I was getting this error:
value too long for type character varying(50)
despite the fact that my models.py had:
slug = AutoSlugField(max_length=255, populate_from='name', unique=True)
and in my db the it the type was
character varying 255
once i remove max_length=255 from the field i.e.
slug = AutoSlugField(populate_from='name', unique=True)
then it worked fine
answered Aug 8, 2015 at 23:30
lukeauslukeaus
11.3k7 gold badges50 silver badges60 bronze badges
1
i went through this same error. and when i made changes in the modele, i kept having the same error.
Here is how i fixed it.
It might be necessary to skip few migrations for the program to only use the migration where changes have been made for the CharField max_lenght.
for that you have to run
python manage.py showmigrations
to see which migrations have not been made.
then you skip them until you get to the last with the command
python manage.py migrate <app> 000_migration_number --fake
answered Jun 4, 2020 at 23:59
I realize the question is already answered but for others that come here when looking for the error message:
In my case the problem was that my table name exceeded 50 characters. Apparently this is not allowed. Changing the table name solved the problem.
Read more here: https://code.djangoproject.com/ticket/18959
answered Sep 1, 2014 at 8:49
Michael Samoylov’s answer pointed me in the right direction. I had the same error come up, except it was with a FileField.
Fields have a max_length, even if you have not explicitly set a max_length. Increase the value so that your data fits to avoid the error.
In my case, the data was too large to reasonably store in the database. I resorted to saving my file to disk, then saving the file path in the database.
answered Jan 11, 2017 at 0:06
Shaun OvertonShaun Overton
5911 gold badge8 silver badges16 bronze badges
1
I had this problem when I wanted to set max_length to a lower value on a FileField.
Interestingly, the error message states value too long but in my case the value was too short.
The solution was to set back the max_length to its old value. It’s quite weird that the migration couldn’t be done.
I also had to delete the wrongly generated migrations files and rerun python manage.py makemigrations and python manage.py migrate.
answered Feb 10 at 9:32
If it’s not SlugField, FileField, or any other field mentioned here—scroll back to where the migration got stuck in the terminal. For me it was AddField
Good talk.
answered Oct 16, 2018 at 23:43
First, try setting max_length to something reasonable on all applicable field types in your model.
For example: MyText = models.CharField(max_length=2000)
If you don’t set a max_length, your database might be applying a default max_length, shorter than the length of your input data, causing your value too long for type character error.
If that doesn’t work and you started in SQLite and changed databases to PostgreSQL, the previous migrations from SQLite might be interfering with the new PostgreSQL migrations.
Go into the migrations folder for your project and delete the old migration files to get a fresh start. Then try makemigrations and migrate again 
answered Mar 27, 2020 at 19:49
2
predefined fields in model.py creates the problem. Extend it to desired length, i think problem will be resolved.
answered Sep 16, 2020 at 6:41
0
For the FileField and the ImageField, from the Django docs:
FileField instances are created in your database as varchar columns with a default max length of 100 characters. As with other fields, you can change the maximum length using the max_length argument.
answered Jun 15, 2021 at 12:40
apetapet
93814 silver badges16 bronze badges
its just enough to remove max_lenght from password field .
answered May 23 at 16:23
1
The value can be 100 or 25 or 17 whatever , the reason behind that is models , search where you have added that particular length(17,25) and you will get the bug ! ,
You are trying to impose a field length more than mentioned one.
This solved my issue , I hope it will help you too
answered May 3, 2021 at 12:59
2
I don’t think you need help fixing this problem, so much as you need help debugging it. Once the problem is clear, the solution seems clear as well. The Traceback is perhaps a bit unclear because it’s going through so much Django source code and it’s not telling you which of your fields is having an issue.
Background To This Issue
To start with, we’re having problems saving a Post instance. Well, look at all of these fields you have in your model definition:
...
url = models.URLField(max_length=250, blank=True, null=True)
video = EmbedVideoField(verbose_name='link',help_text="Youtube", blank=True, null=True)
content = RichTextUploadingField(config_name='default')
image = models.ImageField(upload_to='images',blank=True, null=True)
thumbnail = models.ImageField(upload_to='images', blank=True, null=True)
These may not look like text fields, but a lot of them are variations on text fields because, if you think about it, you’re probably not going to store whole files in your database. What you will do instead (and what Django does by default) is store the file somewhere on some disk and then in the database you would store the path to that file so you can retrieve it when you need to.
Further, it’s probably a waste to store file-paths in the db as LongText or whatever, so every FileField we have means we’ve got a field with a max_length whether we specify it or not. Thus, all of the above fields have an implicit max_length. You can actually find this out by reading the Django source code.
Source Examples
I’ve never used EmbedVideoField, for example, but it turns out to be a subclass of models.URLField, which means it has a max_length by default set to 200 if you do not specify one.
Moreover, your various ImageFields are just subclasses of FileField, which has a max_length default of 100.
How to Debug Problems Like This In the Future?
Now, this doesn’t help us to know which of your fields is throwing an error in this case. For that, I would probably set a breakpoint somewhere in the code, probably here:
File "ebagu/main/models.py" in save
66. super(Post, self).save(*args, **kwargs)
By «set a breakpoint», I mean the following:
Go to line 65 in the module mentioned above, ebagu/main/models.py and enter the following and save the module: import pdb; pdb.set_trace()
(I actually have a strong preference for ipdb myself, but that requires Ipython, which I also have a strong preference for…)
Run your local server, and run through the steps that produced this issue. You will end up submitting your form and if you look at the console where you started your server, you’ll eventually be dumped into a shell right at line 65. This shell is a pdb shell, which has different rules from a normal shell, but you can evaluate your about-to-be-saved Post instance, by looking at the various fields on the instance itself, self, and running Python code in the context of that method call:
(pdb) len(self.image.path)
Using that, I would manually evaluate the various fields and look at which one has this really long entry that is choking the save (probably one of your ImageFields).
Solution with Warnings
Alternately, you can just add a max_length to all of these, but be forewarned that you will most likely need to perform database migrations for any limited text field you change because your database is still going to verify the length of the input against how the column is defined. Here’s a good StackOverflow answer looking at exactly this problem.
Footnote
Why didn’t this come up before you switched to Postgresql? There are a variety of potential reasons, but it probably has to do with how the previous database was setup vs how the Postgresql database was set up (manually vs Django migrations?).
It may also have to do with whether or not you changed where these things are being stored. Did you change your MEDIA settings so the paths where files are stored got a lot longer?
What you really should be doing is looking directly at your database. Open up a psql instance and ask it to describe your tables for you. It’ll tell you which fields are limited to 100 characters and those are the fields giving you problems.
I am aware what this error message Value too long for character type character varying(100) means. So I often look for the rows which cause the trouble and fix them appropriately as deemed fit by the requirement.
But I encountered an odd issue today where the error happens even if there isn’t a rough row.
Failing insert query:
INSERT INTO training.archive_temp1 (id, booking, email, pcd_temp, property_id)
WITH x_pcd AS (
SELECT e.id,
e.booking,
e.email,
CASE
WHEN LENGTH(e.pch) > 0 THEN (e.pch || ':' || e.pcd)
ELSE e.pcd
END AS pcd_temp,
e.pcd
FROM public.extracts_temp AS e WHERE e.id BETWEEN 274939128 AND 275083166
)
SELECT x.id,
x.booking,
x.email,
x.pcd_temp,
COALESCE(c2.property_id, c.property_id)
FROM x_pcd AS x
LEFT JOIN public.property_codes AS c ON x.pcd_temp = c.code
LEFT JOIN public.property_codes AS c2 ON x.pcd = c2.code
WHERE COALESCE(c2.property_id,c.property_id, 0) <> 0;
If I change x.email to x.email::varchar(100) it works.
Here’s the catch.
SELECT max(length(email)) FROM training.archive_temp1;
-- returns 64
Weird. So I checked
SELECT max(length(email)) FROM (
SELECT e.id,
e.booking,
e.email,
CASE
WHEN LENGTH(e.pch) > 0 THEN (e.pch || ':' || e.pcd)
ELSE e.pcd
END AS pcd_temp,
e.pcd
FROM public.extracts_temp AS e WHERE e.id BETWEEN 274939128 AND 275083166
)
-- returns 66
If no row is crossing the character limit of 100, why does it throw the error? What is happening here?
If you need me to share results from any of your queries, please let me know. Since the rows are in 100000 range, can’t share the entire data here and if I could share a minimum verifiable example for the case, I wouldn’t be asking this question.
DatabaseError: слишком длинное значение для меняющегося символа типа (100)
У меня есть веб-сайт Django, на котором запущена мини-CMS, которую мы создали внутри компании много лет назад, она использует postgresql. При сохранении простого заголовка и абзаца текста я получаю следующую ошибку:
value too long for type character varying(100)
Странно то, что ни один столбец не меняется (100), все они 200 или 250, даже значения по умолчанию Django были изменены со 100 на 200 из-за повторно открытый билет, упомянутый здесь
Кто-нибудь знает решение этой проблемы?
person
tdelam
schedule
27.01.2012
source
источник
Ответы (13)
Могу поспорить, что у вас models.SlugField без набора длины. Длина по умолчанию — 50 символов, скорее всего, этого недостаточно. для вашего варианта использования.
Измените его на models.SlugField(max_length=255) и перенесите схему базы данных.
person
Michael Samoylov
schedule
27.01.2012
Это сообщение об ошибке от Postgres, а не от django.
Кажется, вы изменили длину поля в models.py, но это не меняет длину базы данных, которая была создана, когда вы выполнили manage.py syncdb.
Вы должны напрямую изменить длину поля в базе данных.
person
lprsd
schedule
27.01.2012
Django 2.1
Я столкнулся с этой проблемой при переходе с sqlite3 на postgresql. Удалите файлы миграции из папки миграции каждого приложения, кроме __init__.py, затем повторно запустите миграцию.
(venv)myapp$python manage.py makemigrations
(venv)myapp$python manage.py migrate
(venv)myapp$python manage.py runserver
person
7guyo
schedule
31.12.2018
У меня была аналогичная проблема с 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)
тогда это сработало нормально
person
lukeaus
schedule
08.08.2015
Ответ Михаила Самойлова указал мне правильное направление. У меня возникла такая же ошибка, за исключением того, что это было с FileField.
Поля имеют max_length, даже если вы явно не установили max_length. Увеличьте значение, чтобы ваши данные подходили, чтобы избежать ошибки.
В моем случае данные были слишком большими, чтобы их можно было хранить в базе данных. Я прибег к тому, чтобы сохранить свой файл на диск, а затем сохранить путь к файлу в базе данных.
person
Shaun Overton
schedule
11.01.2017
я прошел через ту же ошибку. и когда я внес изменения в модель, у меня продолжалась та же ошибка.
Вот как я это исправил. Возможно, потребуется пропустить несколько миграций, чтобы программа использовала только миграцию, в которой были внесены изменения для CharField max_lenght.
для этого вам нужно бежать
python manage.py showmigrations
чтобы увидеть, какие миграции не были выполнены.
затем вы пропускаете их, пока не дойдете до последнего с помощью команды
python manage.py migrate <app> 000_migration_number --fake
person
Romain BOBOE
schedule
04.06.2020
Я понимаю, что на этот вопрос уже дан ответ, но для других, которые приходят сюда в поисках сообщения об ошибке:
В моем случае проблема заключалась в том, что имя моей таблицы превышало 50 символов. Видимо это недопустимо. Изменение имени таблицы решило проблему.
Подробнее читайте здесь: https://code.djangoproject.com/ticket/18959
person
Ramon de Jesus
schedule
01.09.2014
Если это не SlugField, FileField или любое другое поле, упомянутое здесь — прокрутите назад до места, где миграция застряла в терминале. Для меня это было AddField
Хорошая беседа.
person
Poopy McFartnoise
schedule
16.10.2018
Во-первых, попробуйте установить для max_length какое-нибудь разумное значение для всех применимых типов полей в вашей модели.
Например: MyText = models.CharField(max_length=2000)
Если вы не устанавливаете max_length, ваша база данных может применять max_length по умолчанию, меньшую, чем длина ваших входных данных, что вызывает ошибку value too long for type character.
Если это не сработает и вы начали с SQLite и изменили базы данных на PostgreSQL, предыдущие миграции с SQLite могут мешать новым миграциям PostgreSQL.
Перейдите в папку миграции вашего проекта и удалите старые файлы миграции, чтобы начать все сначала. Затем попробуйте makemigrations и снова выполните миграцию
person
Annaleise
schedule
27.03.2020
предопределенные поля в model.py создают проблему. Увеличьте его до нужной длины, думаю, проблема будет решена.
person
Rabeul Hasan
schedule
16.09.2020
Для FileField и ImageField из документации Django:
Экземпляры FileField создаются в вашей базе данных как столбцы varchar с максимальной длиной по умолчанию 100 символов. Как и в случае с другими полями, вы можете изменить максимальную длину с помощью аргумента max_length.
person
apet
schedule
15.06.2021
Значение может быть 100, 25 или 17, причина в моделях, найдите, где вы добавили эту длину (17,25), и получите ошибку! ,
Вы пытаетесь установить длину поля больше указанной.
Это решило мою проблему, надеюсь, вам это тоже поможет.
person
Saikat Mukherjee
schedule
03.05.2021
Коллеги, приветствую!
Заношу файлы изображений в базу по ссылке.
Получил очень странную ошибку: django.db.utils.DataError: ОШИБКА: значение не умещается в тип character varying(50).
img_name1 = urlparse(image).path.split('/')[-1]
response = requests.get(image)
if response.status_code == 200:
product.image.save(img_name1, ContentFile(response.content), save=True)Ругается на строчку
product.image.save(img_name1, ContentFile(response.content), save=True)
делал принт img_name1, там не больше 6 символов, остается только ContentFile(response.content)
Тогда вопрос, как увеличить лимит? Нагуглить ничего не удалось, увы