Django - Modifica una relazione ForeignKey con OneToOne

Question

Sto utilizzando South con la mia app Django. Ho due modelli che sto cambiando dall'avere una relazione ForeignKey con una relazione OneToOneField. Quando ho eseguito questa migrazione sul mio database di sviluppo, è andato tutto bene. Quando le migrazioni vengono eseguite come parte della creazione di un database di test, la migrazione più recente non riesce con un errore 1005 MySQL: "Impossibile creare table mydb. # Sql-3249_1d (errno: 121)". Fare un po 'su Google ha rivelato che questo è solitamente un problema con il tentativo di aggiungere un vincolo con lo stesso nome di un vincolo esistente. La riga specifica nella migrazione che questo non si verifica è:

Il rapporto è stato modificato da:

class MyModel(models.Model): 
    othermodel = models.ForeignKey(OtherModel) 

a

class MyModel(models.Model): 
    othermodel = models.OneToOneField(OtherModel) 

che ha generato le seguenti istruzioni nella migrazione:

db.alter_column('myapp_mymodel', 'othermodel_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['myapp.OtherModel'], unique=True)) 

db.create_unique('myapp_mymodel', ['othermodel_id']) 

Ma invece di non riuscire sulla chiamata create_unique, non funziona sullo 01 Chiamata. Ho eseguito il seguente comando per vedere quali SQL è stato generato:

python manage.py migrate myapp 0010 --db-dry-run --verbosity=2 

e stampato fuori

myapp:0010_auto__chg_field_mymodel_othermodel__add_unique_mymodel 
    = ALTER TABLE `myapp_mymodel` ADD CONSTRAINT `myapp_mymodel_othermodel_id_uniq` UNIQUE (`othermodel_id`) [] 
    = SET FOREIGN_KEY_CHECKS=1; [] 
    = ALTER TABLE `myapp_mymodel` ADD CONSTRAINT `myapp_mymodel_othermodel_id_uniq` UNIQUE (`othermodel_id`) [] 

Sembra strano che si sta cercando di eseguire il ADD CONSTRAINT due volte, ma se mi tolgo la db.create_unique chiamata, non viene generato SQL quando lo eseguo con --db-dry-run, ma ottengo ancora l'errore se lo eseguo per davvero.

Sono in perdita qui, ogni aiuto è apprezzato.

Answer 1

La prima cosa che proverei sarebbe aggiungere uno db.delete_unique(...) in vari punti per vedere se potrei hackerarlo.

In mancanza di questo, mi piacerebbe dividerlo in 3 migrazioni:

1. una migrazione dello schema per aggiungere una nuova colonna per l'OnetoOne
2. una migrazione dei dati per copiare tutti i valori FK da antica colonna verso new
3. una migrazione dello schema per rimuovere la vecchia colonna, che poi avrei modificato manualmente per includere un comando per rinominare la nuova colonna con la stessa di quella vecchia.

Answer 2

In realtà non è necessaria alcuna migrazione. Le relazioni OneToOne e ForeignKey hanno uno schema di database compatibile sotto l'hook: una colonna semplice con l'altro ID oggetto in una tabella.

Basta falsificare la migrazione con migrate --fake se non si vuole entrare nel problema di dire a sud di ignorare questa modifica.

Answer 3

Sono d'accordo con @ e-satis che l'obiettivo qui è quello di simulare una migrazione, ma suggerisco un approccio diverso se si lavora con una squadra.

Se si crea una migrazione, quindi --fake, tutti i membri del team dovranno ricordarsi di --fake. Se qualcuno di loro non fa questo quando si aggiorna, sei nei guai.

Un approccio migliore è quello di creare una migrazione vuota, poi migrarlo:

manage.py schemamigration yourapp --empty fake_migration_of_foreign_key_to_onetoone 
manage.py migrate # Like you always do!