queryset - models django unique

La columna Django "nombre" de la relación "django_content_type" no existe

Question

Sigo recibiendo el siguiente error cuando realizo una migración (python manage.py migrate):

django.db.utils.ProgrammingError: column "name" of relation "django_content_type" does not exist

He hecho lo siguiente para intentar solucionarlo, pero sin éxito:

1. He eliminado todos los archivos de migraciones para cada modelo
2. borró todos los registros en django_migrations
3. ejecutar python manage.py migrate --fake-initial

Ejecutando Django 1.8.2.

python manage.py showmigrations
admin
[ ] 0001_initial
auth
[ ] 0001_initial
[ ] 0002_alter_permission_name_max_length
[ ] 0003_alter_user_email_max_length
[ ] 0004_alter_user_username_opts
[ ] 0005_alter_user_last_login_null
[ ] 0006_require_contenttypes_0002
contenttypes
[X] 0001_initial
[ ] 0002_remove_content_type_name
hashtags
[ ] 0001_initial
[ ] 0002_hashtagvisit_user
posts
[ ] 0001_initial
[ ] 0002_auto_20150530_0715
sessions
[ ] 0001_initial
users
[ ] 0001_initial

Gracias por la ayuda.

Answer 1

Encontré esto al actualizar a 1.8 y migrar de MySQL a Postgres.

No puedo explicar por qué ocurre el error, pero pude sortearlo agregando manualmente la columna:

1. Eliminar todas las migraciones

2. Eliminar registros de django_migrations

3. Agregar columna de name manualmente:

   ALTER TABLE django_content_type ADD COLUMN name character varying(50) NOT NULL DEFAULT ''someName'';

4. Ejecute la inicial falsa: $ python manage.py migrate --fake-initial

Edición 12/2016 : lo recomiendo como una solución alternativa, más adecuada para proyectos personales o entornos locales y no para entornos de producción. Obviamente, si le importa su historial de migración, este no es el camino a seguir.

Answer 2

Me encontré con el mismo problema hoy, y me gustaría agregar un resumen del problema y cómo resolverlo:

Fuente del problema:

Django 1.8 cambió sus estructuras internas de base de datos y el name la columna ya no existe en la base de datos (ver se toma del atributo verbose_name del modelo ).

Para solucionar esto, se crea automáticamente un tipo de contenttypes migración - 0002_remove_content_type_name .

Normalmente, todas sus migraciones deberían haberse aplicado y esto debería registrarse en la tabla django_migrations y todo debería estar bien.

Si, por ejemplo, hizo una copia de seguridad de su base de datos utilizando dumpdata, borró (eliminó) todo el contenido de la base de datos y cargó el volcado con loaddata, su tabla django_migrations permanece vacía.

Por lo tanto, migrate intenta volver a aplicar todas las migraciones (aunque las tablas ya existan) y falla cuando intenta eliminar el name columna no existente.

Puede verificar si esta situación se aplica revisando su tabla django_migrations o, con mucha mayor python manage.py showmigrations ejecutando python manage.py showmigrations . Si tu situación se ve como

contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name

estás bien (o de hecho estás teniendo un problema diferente), en caso de que se vea así

contenttypes
[ ] 0001_initial
[ ] 0002_remove_content_type_name

te encontraste con la situación descrita arriba. Verifique que su base de datos contenga todas las tablas y todas las columnas (excepto los cambios que quería aplicar con su migración fallida).

Qué hacer / Paso a paso Solución:

Por lo tanto, nuestra estructura de base de datos está bien (excepto por los cambios que quería aplicar con su migración fallida), pero Django / migrate simplemente no lo sabe. Así que déjenos hacer algo al respecto:

1. Dile a Django que todas las migraciones de manage.py migrate --fake contenttypes se han aplicado: manage.py migrate --fake contenttypes . Si desea volver a verificar, ejecute showmigrations .

2. No le digamos a Django que todas las migraciones anteriores a la que desea aplicar se han aplicado. Para esto, necesita el número de migración como se muestra en showmigrations . Por ejemplo, si su situación se ve como

   my_app
   [ ] 0001_initial
   [ ] 0002_auto_20160616_0713

   y su migrate falló al aplicar 0002_auto_20160616_0713 , la última migración aplicada correctamente en su base de datos fue 0001_initial . Wen luego aplica la entrada en django_migrations por python manage.py migrate --fake my_app 0001 (recuerde que el número de migraciones es suficiente). migrate falsificará automáticamente todas las demás migraciones dependientes si es necesario.

3. Ahora podemos aplicar la migración missiong, ¡y esta vez tenemos que hacerlo de verdad y no fingir! Entonces ejecutamos python manage.py migrate my_app . Esto debería alterar la base de datos según sea necesario.

   Si su última migración depende de otras migraciones que no hayan sido falsificadas, debe falsificarlas de antemano.

4. Verificación doble y limpieza: use showmigrations nuevamente para verificar si se han aplicado todas las migraciones. Si hay migraciones abiertas, python manage.py migrate --fake utilizando python manage.py migrate --fake .

Cosas que no debes hacer

• eliminar todas las migraciones: en una configuración de producción, esto podría no ser aplicable porque podrían contener algún trabajo para migrar datos que no deberían perderse.
• agregue manualmente el name la columna a los tipos de contenido; se eliminará luego cuando se aplique la migración. Ok, es un truco de trabajo, pero no aborda el problema.

Cosas que debes hacer

Intenta descubrir cómo te metiste en esta situación y encuentra la forma de evitarla.

Mi problema era que tenía bases de datos diferentes para mi proyecto (sqlite para pruebas de desarrollo rápido, postgres local para pruebas reales, postgres remotos para producción) y quería copiar el contenido de una a otra.

Answer 3

Otra variante que funcionó para mí (de una base de datos en blanco) fue:

./manage.py makemigrations myappname
./manage.py migrate

Una variante que NO funcionó fue:

./manage.py makemigrations myappname
./manage.py migrate myappname

O, mejor dicho, la secuencia aparentemente funcionaría la primera vez, pero no funcionaría la segunda vez, quejándose entonces de que django_content_type no existía.

La variante de trabajo (primeras 2 líneas) de arriba parece ser idempotente.

(editado: para eliminar la segunda línea redundante de la versión original de trabajo de 3 líneas)

Answer 4

Recibí este error después de que decidimos eliminar las migraciones del control de versiones (git) y crear una nueva base de datos desde cero.

Algo que funcionó para mí (aunque para ser sincero, no estoy seguro de por qué) fue ejecutar ''migraciones'' para cada aplicación. entonces, ''python manage.py makemigrations app1'', ''python manage.py makemigrations app2'', y así sucesivamente para cada aplicación de Django.

Finalmente, acabo de ejecutar ''python manage.py migrate'', crucé los dedos, y funcionó.

Cualquier idea sobre cómo / por qué funcionó esto sería útil.

Answer 5

Sé que es una vieja pregunta, pero esto podría ayudar a alguien. Estaba recibiendo este error también. El problema era que content_types tenía una migración llamada 0002_remove_content_type_name que eliminaba la columna "nombre".
Después de eliminar los datos de migración de la tabla y la carpeta, estos pasos me funcionan:

./manage.py makemigrations myappname
./manage.py migrate myappname
./manage.py migrate --fake contenttypes

Si está seguro de que el resto de su db refleja su migración, puede usar:

./manage.py migrate --fake

Ver el resultado con:

./manage.py showmigrations

Después de eso, todas sus migraciones deben marcarse y usted debe estar bien

Answer 6

Tuve el mismo problema, pero pude resolverlo agregando esto a mis dependencias de migración:

(''contenttypes'', ''0002_remove_content_type_name'')

¡Espero eso ayude!