django: "python manage.py migrate" zabierające godziny (i inne dziwne zachowanie)

Question

Wprowadziłem kilka zmian do jednej z moich tabel w models.py i próbowałem przeprowadzić migrację z "python manage.py migrate", a to zajmuje wiele godzin . Zmieniłem tylko nazwy trzech nazw pól (kolumn) i trwa już ponad 2 godziny. Działał sprawnie (myślę) w ciągu kilku minut, kiedy stworzyłem tabelę dziś rano. Początek sezonu to model, w którym dokonano zmian.

Oto co z models.py wygląda teraz:

from django.db import models 
from django.contrib.gis.db import models as gismodels 
# from django.contrib.gis import admin 

# Create your models here. 

class Location(models.Model): # table name automatically chirps_location 
    locationID = models.IntegerField(default=0, primary_key=True) 
    lat = models.FloatField(default=0.0) 
    lon = models.FloatField(default=0.0) 
    geom = gismodels.PointField(null=True) 
    objects = gismodels.GeoManager() 
    def __unicode__(self): 
     return u"LocationID: " + unicode(self.locationID) 

# admin.site.unregister(Location) 
# admin.site.register(Location, admin.OSMGeoAdmin) 


class Rainfall(models.Model): 
    location = models.ForeignKey(Location) 
    year = models.IntegerField(default=0) 
    pentad_num = models.IntegerField(default=0)   
    pentad_val = models.FloatField(default=0.0) 

    class Meta: 
     ordering = ['location', 'year', 'pentad_num'] 

    def __unicode__(self): 
     return u"LocationID: " + unicode(self.location.locationID) + u" Year: " + unicode(self.year) + u" Pentad: " + unicode(self.pentad_num) 


class Start_of_Season(models.Model): 
    location = models.ForeignKey(Location) 
    crop = models.CharField(default='', max_length=40) 
    year = models.IntegerField(default=0) 
    first_rain = models.IntegerField(default=0) 
    onset_rain = models.IntegerField(default=0) 
    start_season = models.IntegerField(default=0) 

    class Meta: 
     ordering = ['location', 'crop', 'year']  

    def __unicode__(self): 
     return u"LocationID: " + unicode(self.location.locationID) + u" Year: " + unicode(self.year) + u" Start of Season pentad: " + unicode(self.start_season) 

Było też trochę dziwne zachowanie, że nie może wyjaśnić dzieje się przed tym, więc dam Krótkie podsumowanie wszystkich także w przypadku, gdy wszystko jest powiązane.

Początkowo moja klasa Start_of_Season wyglądał następująco (zauważ, jedyną różnicą jest to imiona ostatnich 3 pola):

class Start_of_Season(models.Model): 
    location = models.ForeignKey(Location) 
    crop = models.CharField(default='', max_length=40) 
    year = models.IntegerField(default=0) 
    first_rain_pentad = models.IntegerField(default=0) 
    onset_rain_pentad = models.IntegerField(default=0) 
    start_season_pentad = models.IntegerField(default=0) 

    class Meta: 
     ordering = ['location', 'crop', 'year']  

    def __unicode__(self): 
     return u"LocationID: " + unicode(self.location.locationID) + u" Year: " + unicode(self.year) + u" Start of Season pentad: " + unicode(self.start_season) 

Migracja go:

python manage.py makemigrations 
python manage.py migrate 

ukazał się płynnie .

Ale kiedy wpadłem skryptu Pythona (fragment), aby dodać wiersze do tej nowo utworzonej tabeli Start_of_Season:

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "access.settings") 
from chirps.models import Location, Rainfall, Start_of_Season 
django.setup() 

try: 
    with transaction.atomic(): 
     for loc in Location.objects.all(): 
      locID = loc.locationID 
      for yr in range(1981, 2014): 
       # some computations to find: c1, c2, c3 
       start_of_season = Start_of_Season() 
       start_of_season.location = Location.objects.get(locationID = locID) 
       start_of_season.crop = 'millet' 
       start_of_season.year = yr 
       start_of_season.first_rain_pentad = c1 
       start_of_season.onset_rain_pentad = c2 
       start_of_season.start_season_pentad = c3 
       start_of_season.save() 

Początkowo wiersze nigdy nie zostały dodane do bazy danych (zgodnie z psql przynajmniej). Wtedy dostałem błąd "start_of_season nie ma atrybutu start_season" co jest dziwne, ponieważ nigdy nie próbowałem uzyskać dostępu do tego atrybutu w moim skrypcie, tylko "start_of_season.start_season_pentad"

Więc pomyślałem, ok, zmienię imiona pól, aby atrybut start_of_season ma wartość. I wtedy edytowałem models.py, aby wyglądał jak fragment na górze postu.

Po aktualizacji uaktualniania models.py,

python manage.py makemigrations 

prowadził bez błędów:

(access_mw)mwooten@ip-10-159-67-226:~/dev/access$ python manage.py makemigrations 
Did you rename start_of_season.first_rain_pentad to start_of_season.first_rain (a IntegerField)? [y/N] y 
Did you rename start_of_season.onset_rain_pentad to start_of_season.onset_rain (a IntegerField)? [y/N] y 
Did you rename start_of_season.start_season_pentad to start_of_season.start_season (a IntegerField)? [y/N] y 
Migrations for 'chirps': 
    0010_auto_20150901_1454.py: 
    - Rename field first_rain_pentad on start_of_season to first_rain 
    - Rename field onset_rain_pentad on start_of_season to onset_rain 
    - Rename field start_season_pentad on start_of_season to start_season 

, ale:

python manage.py migrate 

został zatrzymany tu godzinami:

(access_mw)mwooten@ip-10-159-67-226:~/dev/access$ python manage.py migrate 
Operations to perform: 
    Synchronize unmigrated apps: staticfiles, gis, djgeojson, messages, leaflet 
    Apply all migrations: admin, chirps, contenttypes, auth, sessions 
Synchronizing apps without migrations: 
    Creating tables... 
    Running deferred SQL... 
    Installing custom SQL... 
Running migrations: 
    Rendering model states... DONE 
    Applying chirps.0010_auto_20150901_1454... 

Nie widzę powodu, dla którego powinno to zająć tyle czasu, ponieważ nie było tworzenia rzeczywistej tabeli. Nie wiem też, dlaczego dostaję inne błędy. Jakieś pomysły co do tego, co się dzieje?

Dzięki

Answer 1

Częściej niż nie jest, ponieważ nie ma innego klienta lub serwera SQL lub powłoki Django odczytu/zapisu do tabeli, którą próbujesz zmodyfikować.

Polecenie SQL, które zmienia schemat, nie może zostać pomyślnie wykonane podczas uzyskiwania dostępu do tabeli. Idealnie powinien pojawić się komunikat o błędzie, ale zwykle dzieje się tak, że polecenie czeka tylko na zakończenie pozostałych.

Po zamknięciu wszystkich otwartych powłok i klientów sql może dojść do zmiany schematu. W najgorszym przypadku może być konieczne tymczasowe przeniesienie witryny do trybu offline.