2013-08-26 6 views
5

Sto avendo un problema quando si applica un django migrazione sud:Stucked in una migrazione sud django - errore TransactionManagement

Come sempre, ho eseguito il comando migrate dopo uno schemamigration successo

python manage.py migrate webapp 

La console di log :

Running migrations for webapp: 
- Migrating forwards to 0020_auto__add_example. 
> webapp:0020_auto__add_example 
TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK 

L'errore non è correlato con la migrazione specifica come se mi spostassi all'indietro e ne provi un altro mostra lo stesso messaggio.

Qualche idea?

Modifica. Questo è il log della query:

(0.005) SELECT `south_migrationhistory`.`id`, `south_migrationhistory`.`app_name`, `south_migrationhistory`.`migration`, `south_migrationhistory`.`applied` FROM `south_migrationhistory` WHERE `south_migrationhistory`.`applied` IS NOT NULL ORDER BY `south_migrationhistory`.`applied` ASC; args=() 
Running migrations for webapp: 
- Migrating forwards to 0020_auto__add_example. 
> webapp:0020_auto__add_example 
(0.002) CREATE TABLE ROLLBACK_TEST (X INT); args=() 
TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK 
+0

È possibile abilitare la registrazione sql e allegare i risultati qui? https://coderwall.com/p/uzhyca – tuxcanfly

+1

@tuxcanfly, l'ho aggiunto. – Miquel

+1

Grazie a tuxcanfly. Almeno ho imparato a registrare il database durante l'esecuzione di query django. – Miquel

risposta

0

scrivo la risposta al problema che ho avuto in quanto può essere utile per qualcuno.

Dopo un po 'di tempo di debug, ho scoperto che il problema non era legato al django. Era un problema con il database e la macchina virtuale che lo ospita.

Ho riavviato il computer del database e le migrazioni ora funzionano.

1

Ho avuto lo stesso problema e per me la soluzione era semplicemente quella di fornire i diritti corretti del mio file sqlite development.db all'utente che stava eseguendo il comando python manage.py migrate webapp. Avevo il file di proprietà di www-data e quindi non poteva funzionare sul file.

3

Ho avuto lo stesso problema e ho sbattuto la testa per un po '. Si scopre che il mio utente di database (MySQL) non ha privilegi sufficienti. Ho assegnato: ALTER, CREATE, DELETE, DROP, INDEX, INSERT, SELECT, UPDATE all'utente e tutto ha funzionato bene.

13

Ho appena avuto un problema simile.

  • MySQL 5.6.13 (su Amazon RDS)
  • Django == 1.5.4
  • MySQL-python == 1.2.4
  • Sud == 0.8.2

Ho esaminato quasi tutte le possibili soluzioni qui e attraverso innumerevoli ricerche su Google con zero fortuna.

Ho esaminato lo schema del database e una tabella che non avevo creato denominata "ROLLBACK_TEST" faceva parte dello schema.

Una volta abbandonato quel tavolo misterioso, la migrazione si è svolta in modo impeccabile.

Questa tabella potrebbe aver avuto origine solo tramite Django, Sud o forse un processo interno su Amazon come nessun altro ha accesso.

+0

Mi sono imbattuto nello stesso problema. Ho interrotto una migrazione e ROLLBACK_TEST era una tabella rimasta nel database. Lasciare quel tavolo a Sud dice che le cose vanno bene. – Adriaan

+1

Nota che potresti incontrare questo problema se il tuo utente DB non ha i privilegi di rilascio – Esteban

0

Quando sono arrivato allo stesso problema il mio problema era più o meno collegato al django. Io spiego.

Stavo lavorando con diverse schede nella mia console. Uno è stato utilizzato con una shell di django per testare i miei modelli e in un'altra scheda eseguo le migrazioni.Sono arrivato a un errore di integrità nella mia scheda della shell. Quindi, fino a quando ho risolto il problema (see this thread) o chiuso la scheda, l'errore nella scheda di migrazione persisteva. Come ha sottolineato la prima risposta, si trattava di qualcosa correlato al DB, ma non alla colpa di DB.

3

Ho avuto lo stesso problema con Django 1.6 e South 1.0 su un'istanza MySQL. Dopo aver acceso il registratore django.db.backends mi sono reso conto della migrazione era bloccato sulla seguente istruzione SQL:

DEBUG (0.003) CREATE TABLE ROLLBACK_TEST (X INT); args=None 

così ho controllato il database e abbastanza sicuro trovato il tavolo ROLLBACK_TEST. L'eliminazione ha risolto il problema:

$ manage.py dbshell 
mysql> DROP TABLE ROLLBACK_TEST;