Переключение проекта Django с бэкенда sqlite3 на ошибки postgresql при загрузке данных - PullRequest
17 голосов
/ 19 июня 2010

В настоящее время я использую sqlite3 в качестве базы данных для одного из моих проектов Django. Я хочу изменить это, чтобы использовать postgresql, и я хотел бы сохранить все данные в целости.

Я использовал ./manage.py dumpdata > dump.json, чтобы создать дамп данных, и изменил мои настройки на использование postgresql. Сначала попытка выполнить пустую базу данных ./manage.py loaddata dump.json привела к ошибкам из-за несуществующих таблиц, поэтому я запустил ./manage.py syncdb и повторил попытку. Это приводит к этой ошибке:

Problem installing fixture 'dump.json': Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/django/core/management/commands/loaddata.py", line 163, in handle
    obj.save()
  File "/usr/lib/python2.6/site-packages/django/core/serializers/base.py", line 163, in save
    models.Model.save_base(self.object, raw=True)
  File "/usr/lib/python2.6/site-packages/django/db/models/base.py", line 495, in save_base
    rows = manager.filter(pk=pk_val)._update(values)
  File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line 448, in _update
    return query.execute_sql(None)
  File "/usr/lib/python2.6/site-packages/django/db/models/sql/subqueries.py", line 124, in execute_sql
    cursor = super(UpdateQuery, self).execute_sql(result_type)
  File "/usr/lib/python2.6/site-packages/django/db/models/sql/query.py", line 2347, in execute_sql
    cursor.execute(sql, params)
  File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 19, in execute
    return self.cursor.execute(sql, params)
IntegrityError: duplicate key value violates unique constraint "django_content_type_app_label_key"
  • Разве это не правильный способ перемещения данных из одной базы данных в другую?
  • Что мне делать, чтобы безопасно переключать бэкэнд БД?

Ответы [ 3 ]

33 голосов
/ 20 июня 2010

Проблема в том, что вы получаете типы контента, определенные дважды - один раз, когда вы делаете syncdb, и один раз из экспортируемых данных, которые вы пытаетесь импортировать.Поскольку у вас вполне могут быть другие элементы в вашей базе данных, которые зависят от исходных определений типов контента, я бы порекомендовал сохранить их.

Итак, после запуска syncdb выполните manage.py dbshell, а в вашей базе данных выполните TRUNCATE django_content_type; удалить все вновь определенные типы контента.Тогда не должно быть никаких конфликтов - в любом случае, на этой части процесса.

2 голосов
/ 04 апреля 2011

Существует большая дискуссия об этом на билете Django 7052 . Теперь правильным способом является использование параметра --natural, например: ./manage.py dumpdata --natural --format=xml --indent=2 > fixture.xml

Чтобы --natural работал с вашими моделями, они должны реализовывать natural_key и get_by_natural_key, как описано в документации Django относительно естественных ключей .

Сказав это, вам, возможно, все же потребуется отредактировать данные, прежде чем импортировать их с помощью ./manage.py loaddata. Например, если ваши приложения изменились, syncdb заполнит таблицу django_content_type, и вы можете удалить соответствующие записи из xml-файла перед его загрузкой.

0 голосов
/ 04 апреля 2016

Это сработало для меня. Вы, вероятно, хотите убедиться, что сервер остановлен, поэтому новые данные не будут потеряны. Дамп это:

$ python manage.py dumpdata --exclude auth.permission --exclude contenttypes --natural > db.json

Убедитесь, что ваши модели не имеют сигналов (например, post_save) или чего-либо, что создает модели. Если вы это сделаете, закомментируйте это на мгновение.

Отредактируйте файл settings.py, чтобы он указывал на новую базу данных, и установите ее:

$ python manage.py syncdb

$ python manage.py migrate

Загрузить данные:

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