Django South-table ya existe

django-south

Question

Estoy tratando de comenzar con South. Tenía una base de datos existente y agregué South ( syncdb , schemamigration --initial ).

Luego, actualicé models.py para agregar un campo y ejecuté ./manage.py schemamigration myapp --auto . Parecía encontrar el campo y dijo que podía aplicar esto con ./manage.py migrate myapp . Pero, al hacerlo, dio el error:

django.db.utils.DatabaseError: table "myapp_tablename" already exists

tablename es la primera tabla enumerada en models.py .

Estoy ejecutando Django 1.2, South 0.7

Answer 1

Aunque la tabla "myapp_tablename" ya existe, el error deja de aumentar después de hacerlo ./manage.py migrate myapp --fake, DatabaseError no muestra dicha columna: myapp_mymodel.added_field.

Tengo exactamente el mismo problema!

1. Primero, verifique el número de migración que está causando esto. Supongamos que es: 0010.

2.Necesitas:

./manage.py schemamigration myapp --add-field MyModel.added_field
./manage.py migrate myapp

si falta más de un campo, debe repetirlo para cada campo.

3. Ahora aterriza con un grupo de migraciones nuevas, por lo tanto, elimine sus archivos de myapp / migrations (0011 y más si necesita agregar múltiples campos).

4. Ejecuta esto:

./manage.py migrate myapp 0010

Ahora prueba ./manage.py migrate myapp

Si no falla, estás listo. Simplemente haga una doble comprobación si no falta ningún campo.

EDITAR:

Este problema también puede ocurrir cuando tiene una base de datos de producción para la cual instala South y la primera, la migración inicial creada en otro entorno duplica lo que ya tiene en su base de datos. La solución es mucho más fácil aquí:

1. Falso la primera migración:

   ./manage migrate myapp 0001 --fake

2. Rodar con el resto de migraciones:

   ./manage migrate myapp

Answer 2

Como solución temporal, puede comentar la creación de tabla en el script de migración.

class Migration(migrations.Migration):
dependencies = [
(...)
]
operations = [
#migrations.CreateModel(
# name=''TABLE'',
# fields=[
# ....
# ....
# ],
#),
....
....

O

Si la tabla existente no contiene filas (vacías), considere eliminar la tabla siguiente. (Esta corrección solo se recomienda si la tabla no contiene filas) . También asegúrese de esta operación antes de la operación createModel.

class Migration(migrations.Migration):
dependencies = [
(...),
]
operations = [
migrations.RunSQL("DROP TABLE myapp_tablename;")
]

Answer 3

Cuando me encontré con este error, tenía una causa diferente.

En mi caso, South había dejado de alguna manera en mi base de datos una tabla vacía temporal, que se usa en _remake_table() . Probablemente aborté una migración de una manera que no debería haber tenido. En cualquier caso, cada nueva migración posterior, cuando llamaba a _remake_table (), arrojaba el error sqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already exists , porque ya existía y no se suponía que estuviera allí.

El nuevo bit del sur me pareció extraño, así que busqué mi DB, vi la mesa _south_new_myapp_mymodel , me _south_new_myapp_mymodel la cabeza, miré _remake_table() , decidí que era basura, dejé caer la mesa, y todo estaba bien.

Answer 4

Si tiene problemas con los modelos que no coinciden con su base de datos, como @pielgrzym, y desea migrar automáticamente la base de datos para que coincida con el archivo models.py más reciente (y borre cualquier dato que los dispositivos no puedan recrear durante la migrate ):

manage.py schemamigration myapp --initial
manage.py migrate myapp --fake
manage.py migrate myapp zero
manage.py migrate myapp

Esto solo eliminará y volverá a crear las tablas de la base de datos que existen en su último archivo models.py , por lo que puede tener tablas de basura en su base de datos de syncdb s anteriores o migrate s. Para deshacerse de ellos, preceda todas estas migraciones con:

manage.py sqlclear myapp | manage.py sqlshell

Y si eso todavía deja algo de CRUFT por ahí en su base de datos, entonces tendrá que hacer una inspectdb y crear el archivo models.py de eso (para las tablas y la aplicación que desea borrar) antes de hacer el sqlclear y luego restaurar su original models.py antes de crear la migración --initial y migrar a ella. Todo esto para evitar jugar con el sabor particular de SQL que su base de datos necesita.

Answer 5

Si tiene una base de datos y una aplicación, puede usar el comando south conversion

./manage.py convert_to_south myapp

Esto debe aplicarse antes de realizar cambios en lo que ya está en la base de datos.

El comando convert_to_south solo funciona completamente en la primera máquina en la que lo ejecuta. Una vez que haya cometido las migraciones iniciales que realizó en su VCS, deberá ejecutar ./manage.py migrate myapp 0001 --fake en cada máquina que tenga una copia de la base de código (asegúrese de que estén actualizados) fecha con modelos y esquema primero). ref: http://south.readthedocs.org/en/latest/convertinganapp.html

Answer 6

Una solución más (tal vez una solución temporal).

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

p.ej.,.

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

Esto mostrará una lista de todas las migraciones en consultas sql sin formato. Puede elegir las consultas que desea ejecutar evitando la parte que crea la tabla existente

Answer 7

dado que ya tiene las tablas creadas en la base de datos, solo necesita ejecutar la migración inicial como falsa

./manage.py migrate myapp --fake

asegúrese de que el esquema de los modelos sea el mismo que el esquema de las tablas en la base de datos.

Answer 8

Perform these steps in order may help you :

1) python manage.py schemamigration apps.appname --initial

El paso anterior crea una carpeta de migración como predeterminada.

2) python manage.py migrate apps.appname --fake

genera una migración falsa.

3) python manage.py schemamigration apps.appname --auto

Luego puede agregar campos como desee y realizar el comando anterior.

4) python manage.py migrate apps.appname