stucked w django południowej migracji - błąd TransactionManagement

Question

Mam problemy przy stosowaniu django południowej migracji:

Jak zawsze, wykonywane komendy MIGRATE po udanym schemamigration

python manage.py migrate webapp 

Konsola dziennika :

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 

błąd nie jest związane z konkretnym migracji jakbym przesunąć do tyłu i spróbować innego pokazuje ten sam komunikat.

Wszelkie pomysły?

Edytuj. To jest dziennik zapytania:

(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 

Answer 1

Piszę odpowiedź na problem, który miałem, ponieważ może być użyteczny dla kogoś.

Po pewnym czasie debugowania okazało się, że problem nie był związany z django. To był problem z bazą danych i maszyną wirtualną, która go obsługuje.

Uruchomiłem ponownie komputer bazy danych i migracje już działają.

Answer 2

Miałem ten sam problem, a dla mnie rozwiązaniem było po prostu przekazanie praw do pliku sqlite development.db użytkownikowi, który wykonywał polecenie python manage.py migrate webapp. Miałem plik należący do www-data i dlatego nie mógł pracować nad plikiem.

Answer 3

Miałem ten sam problem i waliłem w głowę przez chwilę. Okazuje się, że mój użytkownik bazy danych (MySQL) nie miał wystarczających uprawnień. Przypisałem: ALTER, UTWÓRZ, USUŃ, USUŃ, INDEKS, WSTAW, WYBIERZ, AKTUALIZUJ do użytkownika i wszystko działało dobrze.

Answer 4

Po prostu wpadłem na podobny problem.

• MySQL 6.05.13 (na Amazon RDS)
• Django == 1.5.4
• MySQL-python == 1.2.4
• Południowa == 0.8.2

Przeszedłem prawie każdą możliwą poprawkę tutaj i przez niezliczoną ilość wyszukiwań w Google bez szczęścia.

Zajrzałem do schematu bazy danych i tabela, której nie utworzyłem o nazwie "ROLLBACK_TEST" była częścią schematu.

Kiedy upuściłem ten tajemniczy stół, migracja przebiegła bezbłędnie.

Ta tabela mogła pochodzić wyłącznie z Django na południu lub z wewnętrznego procesu Amazon, ponieważ nic innego nie ma do niego dostępu.

Answer 5

Kiedy doszedłem do tego samego problemu, mój problem był mniej lub bardziej związany z django. Wyjaśniam.

Pracowałem z różnymi zakładkami w mojej konsoli. Jeden został użyty z powłoką django do przetestowania moich modeli iw innej zakładce uruchomiłem migracje.Doszedłem do błędu integralności w zakładce powłoki. Tak więc, dopóki nie rozwiązałem problemu (see this thread) lub nie zamknąłem karty, błąd karty migracji pozostał. Jak wskazała poprzednia odpowiedź, było to coś związanego z DB - ale nie z winy DB.

Answer 6

Miałem ten sam problem z Django 1.6 i South 1.0 na instancji MySQL. Po włączeniu rejestratora django.db.backends zdałem sobie sprawę, migracja utknął na następującą instrukcję SQL:

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

Więc sprawdziłem bazę danych i na pewno wystarczy znaleźć ROLLBACK_TEST tabeli. Usunięcie go rozwiązało problem:

$ manage.py dbshell 
mysql> DROP TABLE ROLLBACK_TEST;