Django + Postgres: "текущая транзакция прерывается, команды игнорируются до конца транзакционного блока"

Я начал работать на сайте Django/Postgres. Иногда я работаю в manage.py shell и случайно делаю какое-то действие DB, которое приводит к ошибке. Тогда я не могу вообще выполнять действие с базой данных, потому что для любого действия базы данных, которое я пытаюсь сделать, я получаю ошибку:

current transaction is aborted, commands ignored until end of transaction block

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

(Я читал этот и этот, но они не дают действенных инструкций о том, что делать из оболочки.)

ОТВЕТЫ

Ответ 2

это случается со мной иногда, часто это отсутствует

manage.py migrate

или

manage.py syncdb

как упоминалось здесь и здесь

это также может произойти наоборот, если у вас есть схематизация, ожидающая рассмотрения с ваших моделей .py. С юга вам нужно обновить схему с помощью.

manage.py schemamigration mymodel --auto

Ответ 3

Проверьте это

Быстрый ответ, как правило, заключается в том, чтобы включить автосоздание уровня базы данных, добавив:

'OPTIONS': {'autocommit': True,}

К настройкам базы данных.

Ответ 4

У меня была эта ошибка после восстановления резервной копии до абсолютно пустой БД. Он ушел после запуска:

./manage syncdb

Возможно, в дампе отсутствовали внутренние модели...

Ответ 5

ПРЕДУПРЕЖДЕНИЕ: патч ниже может привести к тому, что транзакции остаются в открытом состоянии на db (по крайней мере, с postgres). Не 100% уверены в этом (и как исправить), но я настоятельно рекомендую не делать патч ниже в производственных базах данных.

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

Когда я запускаю Django-shell, я исправляю Django, чтобы закрыть соединение с БД, как только возникнут какие-либо ошибки. Таким образом, мне никогда не придется думать об откате транзакций или обработке соединения.

Это код, который я загружаю в начале моего сеанса Django-shell:

from django import db
from django.db.backends.util import CursorDebugWrapper
old_execute = CursorDebugWrapper.execute
old_execute_many = CursorDebugWrapper.executemany

def execute_wrapper(*args, **kwargs):
    try:
        old_execute(*args, **kwargs)
    except Exception, ex:
        logger.error("Database error:\n%s" % ex)
        db.close_connection

def execute_many_wrapper(*args, **kwargs):
    try:
        old_execute_many(*args, **kwargs)
    except Exception, ex:
        logger.error("Database error:\n%s" % ex)
        db.close_connection

CursorDebugWrapper.execute = execute_wrapper
CursorDebugWrapper.executemany = execute_many_wrapper

Ответ 6

Если вы столкнулись с такой ошибкой при запуске migrate (Юг), возможно, у вас много изменений в схеме базы данных и вы хотите обрабатывать их все сразу. Postgres немного противно. То, что всегда работает, состоит в том, чтобы разбить одну большую миграцию на более мелкие шаги. Скорее всего, вы используете систему контроля версий.

  • Текущая версия
  • Commit n1
  • Commit n2
  • Commit n3
  • Commit n4 # db changes
  • Commit n5
  • Commit n6
  • Commit n7 # db changse
  • Commit n8
  • Commit n9 # db changes
  • Commit n10

Итак, имея описанную выше ситуацию, сделайте следующее:

  • Резервировать чек на "n4", затем синхронизировать и мигрировать.
  • Оформить репозиторий на "n7", затем синхронизировать и перенести.
  • Резервировать чек на "n10", затем синхронизировать и мигрировать.

И все готово.:)

Он должен работать безупречно.

Ответ 7

Если вы используете версию django до 1.6, вам следует использовать отличный модуль xact.

xact - это рецепт обработки транзакций разумно в приложениях Django на PostgreSQL.

Примечание.. По состоянию на Django 1.6 функциональность xact будет объединена с ядром Django в качестве атомарного декоратора. Код, который использует xact, должен быть перенесен на атомарный с помощью простого поиска и замены. атомные работы в базах данных, отличных от PostgreSQL, являются потокобезопасными и имеют другие приятные функции; переключитесь на него, когда сможете!

Ответ 8

Я добавляю следующее в свой файл настроек, потому что мне нравится функция autocommit, когда я "играю", но не хочу, чтобы он был активным, когда мой сайт работает иначе.

Итак, чтобы получить autocommit только в оболочке, я делаю этот маленький взлом:

import sys
if 'shell' in sys.argv or sys.argv[0].endswith('pydevconsole.py'):
    DATABASES['default']['OPTIONS']['autocommit'] = True

ПРИМЕЧАНИЕ. Эта вторая часть только потому, что я работаю в PyCharm, которая напрямую не запускает manage.py

Ответ 9

Я получил эту ошибку в Django 1.7. Когда я прочитал в документацию, которая

Эта проблема не может возникнуть в режиме Djangos по умолчанию и atomic() обрабатывает его автоматически.

Я немного подозрительно. Ошибки произошли, когда я попытался выполнить миграцию. Оказалось, что некоторые из моих моделей имели my_field = MyField(default=some_function). Если эта функция по умолчанию для поля работала хорошо с sqlite и mysql (у меня были некоторые ошибки импорта, но мне удалось заставить ее работать), хотя, похоже, это не работает для postgresql, и она сломала миграции до такой степени, что я не событие получило полезное сообщение об ошибке, но вместо этого было указано название вопроса.