Слишком длинное значение для переменной типа символа (255) SQLite3 до Postgres Django - PullRequest
1 голос
/ 15 февраля 2020

Я перешел с использования SQLite3 на Postgres для моего приложения Django.

Я выполнил эти команды, чтобы получить все свои данные из базы данных SQLite3, и я хотел добавить их в базу данных Postgres:

python manage.py dumpdata > db.json
python manage.py loaddata db.json

Затем я получил эту ошибку:

Could not load database.Object(pk=XXXXXXXXXX): value too long for type character varying(255)

В моем models.py значение max_length установлено равным 10, а значение первичного ключа равно 10.

Вот как я устанавливаю первичный ключ для модели этого объекта:

models.CharField(max_length=10, unique=True, primary_key=True)

Почему я получаю эту ошибку? У меня есть много других тем об этой проблеме, но я еще не нашел ответ, который решил бы мою проблему.

1 Ответ

2 голосов
/ 15 февраля 2020

SQLite использует динамическую форму c, набрав (выделено жирным шрифтом):

В SQLite тип данных значения связан с самим значением, а не с его контейнер. Динамическая система типа SQLite c обратно совместима с более распространенными системами типов stati c других механизмов баз данных в том смысле, что операторы SQL, которые работают со статически типизированными базами данных, должны работать в SQLite таким же образом. Тем не менее, динамическая c типизация в SQLite позволяет ему делать то, что невозможно в традиционных жестко типизированных базах данных.

Одна из «жестких» вещей, которые она не делает необходимо выполнить длину столбцов:

Обратите внимание, что в скобках указаны аргументы числового значения c, следующие за именем типа (например, "VARCHAR (255)"), SQLite не навязывает никаких ограничения длины (кроме большого глобального SQLITE_MAX_LENGTH предела) для длины строк, больших двоичных объектов или числовых значений c.

Похоже, у вас есть некоторые данные, которые не ' на самом деле вписывается в типы столбцов, которые вы определили Теперь, когда вы переходите на PostgreSQL, вам, возможно, придется вручную исправить некоторые данные или соответственно скорректировать свои модели.

Попробуйте выполнить что-то вроде

select * from app_table order by length(column) desc limit 1;

, чтобы увидеть, какое на самом деле самое длинное значение в этом столбце. Затем либо расширьте свою модель или исправьте данные.

В дополнение, неясно, переносите ли вы весь рабочий процесс на PostgreSQL или просто пытаетесь скопировать данные из разработки в производство. Я настоятельно призываю вас использовать Postgres в разработке, если это база данных, на которую вы будете ориентироваться в работе.

Проблема, с которой вы столкнулись сейчас, является отличным примером того, как одна СУБД не является заменой другого. Вы хотите найти эти проблемы в процессе разработки, а не при попытке развертывания в рабочей среде.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...