django：'python manage.py migrate'需要几个小时（和其他怪异的行为） [英] django: 'python manage.py migrate' taking hours (and other weird behavior)

问题描述

我对models.py中的一个表进行了一些更改，并尝试使用python manage.py migrate进行迁移，而且需要几个小时。我只更改了三个字段（列）名称的名称，现在已经运行了2个多小时。当我今天早上创建桌子的时候，它跑得很顺利（我想）。季节开始是改变的模式。

这里是从models.py看起来像现在：

 从django.db导入模型
从django.contrib.gis.db导入模型作为gismodel 
＃从django.contrib.gis导入admin 
 
＃在这里创建您的模型。 
 
类位置（models.Model）：＃表名自动chirps_location 
 locationID = models.IntegerField（默认= 0，primary_key = True）
 lat = models.FloatField = 0.0）
 lon = models.FloatField（default = 0.0）
 geom = gismodels.PointField（null = True）
 objects = gismodels.GeoManager（）
 def __unicode __ ）
 return uLocationID：+ unicode（self.locationID）
 
＃admin.site.unregister（位置）
＃admin.site.register（位置，管理员$ o 
 
 
 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 uLocationID：+ unicode（self.location.locationID）+ u 年：+ unicode（self.year）+ uPentad：+ 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 = 0）
 onset_rain = models.IntegerField（default = 0）
 start_season = models.IntegerField（default = 0）
 
 class Meta：
 ordering = [' 
 
 def __unicode __（self）：
 return uLocationID：+ unicode（self.location.locationID）+ u年份 + unicode（self.year）+ u开始季节pentad：+ unicode（self.start_season）
  

还有一些奇怪的行为，我在此之前无法解释，所以我将简要介绍一下所有这些都是相关的。

首先，我的Start_of_Season类的样子这样（注意唯一的区别是最后3个字段的名称）：

  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）
 starting_rain_pentad = models.IntegerField（default = 0）
 start_season_pentad = models.IntegerField（default = 0）
 
 class Meta：
 orders = ['location'，'crop'，'year'] 
 
 def __unicode __（self）：
 return uLocationID：+ unicode（self.location.locationID） + u年份+ unicode（self.year）+ u开始季节五元组：+ unicode（self.start_season）
  

将其移植到：

  python manage.py makemigrations 
 python manage.py migrate 
  

似乎顺利运行。

但是当我运行一个python脚本（摘录）来添加行到这个新创建的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 location.objects.all（）：
 locID = loc.locationID 
 for yr in range（1981，2014）：
＃some calculation找到：c1，c2，c3 
 start_of_season = Start_of_Season（）
 start_of_season.location = Location.objects.get（locationID = locID）
 start_of_season.crop ='小米'
 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 （）
  

首先，这些行从未添加到数据库（至少根据psql）。然后我得到错误start_of_season没有属性start_season这是奇怪的，因为我从来没有尝试访问我的脚本中的属性，只有start_of_season.start_season_pentad

那么那么我想，好的，我会更改字段的名称，以便start_of_season 有具有该属性。那就是当我编辑models.py看起来像帖子顶部的摘录。

更新更新models.py后，

  python manage.py makemigrations 
  

运行没有错误：

 （access_mw）mwooten @ ip-10-159-67-226：〜/ dev / access $ python manage.py makemigrations 
您是否将start_of_season.first_rain_pentad重命名为start_of_season.first_rain一个整数字段）？ [y / N] y 
您是否将start_of_season.onset_rain_pentad重命名为start_of_season.onset_rain（IntegerField）？ [y / N] y 
您是否将start_of_season.start_season_pentad重命名为start_of_season.start_season（一个整数字段）？ [y / N] y 
'chirps'的迁移：
 0010_auto_20150901_1454.py：
  - 将start_of_season中的first_rain_pentent重命名为first_rain 
  - 在start_of_season将重命名字段starting_rain_pentad重新发送到onset_rain 
  - 在start_of_season上重命名字段start_season_pentad start_season 
  

，但是：

  python manage.py migrate 
  

已经停留了几个小时：

 （access_mw）mwooten @ ip-10-159-67-226：〜/ dev /访问$ python manage.py migrate 
要执行的操作：
同步未迁移的应用程序：staticfiles，gis，djgeojson，消息，leaflet 
应用所有迁移：admin，chirps，contenttypes，auth，sessions 
不进行迁移同步应用程序：
创建表... 
运行延迟SQL ... 
安装自定义SQL ... 
运行迁移：
渲染模型状态... DONE 
应用chirps.0010_auto_20150901_1454 ... 
  

我不明白为什么这应该需要这么长时间，看看如何创建实际的表没有。我也不知道为什么我得到其他错误。关于发生什么的任何想法？

谢谢

解决方案

更多通常这不是因为有另一个SQL客户端或django服务器或shell读/写到您正在尝试修改的表。

更改一个正在访问表时无法成功执行模式。理想情况下，弹出一个错误消息，但通常会发生的是该命令只是等待其他人完成。

一旦你关闭了所有的打开的shell和sql客户端，模式更改可能会发生。在最坏的情况下，您可能需要暂时使网站脱机。

I made some changes to one of my tables in models.py and tried migrating it with 'python manage.py migrate,' and it's taking hours. I only changed the names of three field (column) names, and it's been running for over 2 hours now. It ran smoothly (I think) in a matter of minutes when I created the table earlier this morning. Start of season is the model where changes were made.

Here is what from models.py looks like now:

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)

There was also some weird behavior that I couldn't explain going on before this, so I'll give a brief rundown of all of that too in case it's all related.

At first, my Start_of_Season class looked like this (notice the only difference is the names of the last 3 fields):

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)

Migrating it with:

python manage.py makemigrations
python manage.py migrate

appeared to run smoothly.

But when I ran a python script (excerpt) to add rows to this newly created Start_of_Season table:

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

At first, the rows were never added to the database (according to psql at least). Then I got the error "start_of_season has no attribute start_season" which is weird because I never tried to access that attribute in my script, only "start_of_season.start_season_pentad"

So then I thought, okay, I'll change the names of the fields so that start_of_season does have that attribute. And that's when I edited models.py to look like the excerpt at the top of the post.

After updating updating models.py,

python manage.py makemigrations

ran with no errors:

(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

, but:

python manage.py migrate

has been stuck here for hours:

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

I don't see why this should take so long, seeing as how creating the actual table didn't. I'm also not sure why I was getting the other errors. Any ideas as to what's going on?

Thanks

解决方案

More often than not this is because there is another SQL client or django server or shell reading/writing to the table that you are trying to modify.

An SQL command that changes a schema cannot be successfully executed while a table is being accessed. Ideally an error message should pop up but what usually happens is that the command just waits for the others to finish.

Once you close all your open shells, and sql clients, the schema change can happen. In the worst case, you might need to temporarily take the site offline too.

这篇关于django：'python manage.py migrate'需要几个小时（和其他怪异的行为）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！