django - mac - error loading psycopg2 module: no module named ''psycopg2''

Django+Postgres: "la transacción actual se cancela, los comandos se ignoran hasta el final del bloque de transacción"

Question

Empecé a trabajar en un sitio de Django / Postgres. A veces trabajo en el manage.py shell , y accidentalmente realizo alguna acción DB que da como resultado un error. Entonces no puedo hacer ninguna acción de base de datos, porque para cualquier acción de base de datos que intento hacer, obtengo el error:

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

Mi solución actual es reiniciar el shell, pero debería encontrar una manera de arreglar esto sin abandonar mi sesión de shell.

(He leído this y this , pero no dan instrucciones procesables sobre qué hacer desde el shell).

Answer 1

Agregué lo siguiente a mi archivo de configuración, porque me gusta la función de confirmación automática cuando estoy "jugando", pero no quiero que esté activo cuando mi sitio se está ejecutando de otra manera.

Entonces, para hacer autocommit solo en shell, hago este pequeño truco:

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

NOTA: Esa segunda parte es solo porque trabajo en PyCharm, que no ejecuta directamente manage.py

Answer 2

Puedes intentar esto:

from django.db import connection
connection._rollback()

La discusión más detallada de este problema se puede encontrar aquí

Answer 3

Recibí este error en Django 1.7. Cuando leo en la documentación que

Este problema no puede ocurrir en el modo predeterminado de Django y atomic () lo maneja automáticamente.

Tengo un poco sospechoso. Los errores ocurrieron cuando intenté ejecutar migraciones. Resultó que algunos de mis modelos tenían my_field = MyField(default=some_function) . Tener esta función como valor predeterminado para un campo funcionó bien con sqlite y mysql (tuve algunos errores de importación, pero logré hacerlo funcionar), aunque parece que no funciona para postgresql, y rompió las migraciones hasta el punto de que no obtuvo un mensaje de error útil, sino el del título de la pregunta.

Answer 4

Si está utilizando una versión de django antes de la versión 1.6, entonces debe usar el excelente módulo xact Christophe.

xact es una receta para manejar transacciones sensatamente en aplicaciones de Django en PostgreSQL.

Nota: A partir de Django 1.6, la funcionalidad de xact se fusionará en el núcleo de Django como el decorador atómico. El código que usa xact debe poder migrarse a atómico con solo buscar y reemplazar. atomic funciona en bases de datos que no sean PostgreSQL, es seguro para subprocesos y tiene otras características interesantes; ¡Cambia a él cuando puedas!

Answer 5

Si se produce un error de este tipo al ejecutar migrate (South), es posible que tenga muchos cambios en el esquema de la base de datos y quiera manejarlos todos a la vez. Postgres es un poco asqueroso con eso. Lo que siempre funciona, es dividir una gran migración en pasos más pequeños. Lo más probable es que estés usando un sistema de control de versiones.

• Tu versión actual
• Commit n1
• Commit n2
• Commit n3
• Commit n4 # db cambios
• Commit n5
• Commit n6
• Commit n7 # db changse
• Commit n8
• Commit n9 # db cambios
• Commit n10

Entonces, teniendo la situación descrita arriba, haga lo siguiente:

• Revise el repositorio en "n4", luego syncdb y migre.
• Revise el repositorio en "n7", luego syncdb y migre.
• Revise el repositorio en "n10", luego syncdb y migre.

Y tu estas listo. :)

Debería funcionar sin problemas.

Answer 6

Tuve este error después de restaurar una copia de seguridad a un DB totalmente vacío. Se fue después de correr:

./manage syncdb 

Tal vez había algunos modelos internos que faltaban en el basurero ...

Answer 7

esto me pasa a veces, a menudo es la falta

manage.py migrate 

o

manage.py syncdb

como se menciona también aquí

también puede ocurrir al revés, si tiene una migración de esquema pendiente de su models.py. Con south necesitas actualizar el esquema con.

manage.py schemamigration mymodel --auto

Answer 8

Mira esto

La respuesta rápida generalmente es activar el compromiso automático a nivel de base de datos al agregar:

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

Para la configuración de la base de datos.

Answer 9

ADVERTENCIA: el siguiente parche puede posiblemente causar que las transacciones queden en un estado abierto en el db (al menos con postgres). No estoy 100% seguro de eso (y de cómo solucionarlo), pero recomiendo encarecidamente no hacer el siguiente parche en las bases de datos de producción.

Como la respuesta aceptada no resuelve mis problemas, tan pronto como recibo un error en la base de datos, no puedo hacer ninguna acción nueva de la base de datos, incluso con una reversión manual, se me ocurrió mi propia solución.

Cuando estoy ejecutando Django-shell, parcho a Django para cerrar la conexión de base de datos tan pronto como se produce un error. De esa forma, nunca más tendré que pensar en deshacer transacciones o manejar la conexión.

Este es el código que estoy cargando al comienzo de mi sesión de 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