django: "python manage.py migrate" prendendo ore (e altri comportamenti strani)

Question

Ho apportato alcune modifiche a una delle mie tabelle in models.py e ho provato a migrarlo con "python manage.py migrate" e ci sono volute ore . Ho solo cambiato i nomi di tre nomi di campi (colonne) ed è attivo da più di 2 ore. Ha funzionato senza problemi (credo) in pochi minuti quando ho creato il tavolo questa mattina. L'inizio della stagione è il modello in cui sono state apportate modifiche.

Ecco cosa da models.py appare come ora:

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) 

C'era anche qualche comportamento strano che non ho potuto spiegare in corso prima di questo, quindi ti darò un breve riepilogo di tutti anche questo nel caso sia tutto collegato.

In un primo momento, la mia classe Start_of_Season si presentava così (si noti l'unica differenza è i nomi degli ultimi 3 campi):

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) 

Migrazione con:

python manage.py makemigrations 
python manage.py migrate 

apparso per eseguire senza problemi .

Ma quando ho eseguito uno script python (estratto) per aggiungere righe a questa tabella Start_of_Season appena creata:

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() 

In un primo momento, le righe non sono mai stati aggiunti al database (secondo psql almeno). Poi ho ricevuto l'errore "start_of_season ha nessun attributo start_season" che è strano perché non ho mai provato ad accedere a quell'attributo nel mio script, solo "start_of_season.start_season_pentad"

Quindi ho pensato, okay, cambierò i nomi dei campi in modo che start_of_season non abbia questo attributo. E quello è quando ho modificato models.py per assomigliare al brano in cima al post.

Dopo aver aggiornato l'aggiornamento models.py,

python manage.py makemigrations 

corse senza errori:

(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 

, ma:

python manage.py migrate 

è stato bloccato qui per ore:

(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... 

Non vedo perché questo dovrebbe richiedere così tanto tempo, visto che la creazione della tabella reale non ha funzionato. Non sono nemmeno sicuro del perché stavo ottenendo gli altri errori. Qualche idea su cosa sta succedendo?

Grazie

Answer 1

Il più delle volte questo è perché c'è un altro client SQL o un server Django o la lettura shell/scrittura al tavolo che si sta cercando di modificare.

Un comando SQL che modifica uno schema non può essere eseguito correttamente mentre si accede a una tabella. Idealmente dovrebbe apparire un messaggio di errore, ma quello che succede di solito è che il comando aspetta solo che gli altri finiscano.

Una volta chiuse tutte le shell aperte e i client sql, è possibile che si verifichi la modifica dello schema. Nel peggiore dei casi, potresti dover temporaneamente portare il sito offline.