我不是专家，但我认为使用Class定义选择并用这些选择预填充数据库是一个好主意。我认为这样更容易更改选择等
所以models.py我有：
class City(models.Model):
name = models.CharField(max_length=32)
distance = models.SmallIntegerField(blank=True, null=True)
#etc
class OtherClass(models.Model):
name = models.CharField(max_length=32)
#etc
class UserProfile(models.Model):
name = models.CharField(max_length=32)
city = models.ForeignKey(City)
otherfield = models.ForeignKey(OtherClass)
#etc
UserProfile是什么用户编译City，OtherClass是程序员放哪里的选项。
迁移后，我要创造一些City和OtherClass对象：他们将是（他们必须是固定的，是）选项。
我只是了解这些装置。到目前为止，我一直在使用script：
import os
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'sitopossedimenti.settings')
import django
django.setup()
from core.models import *
def populate():
namecity1 = add_source('city1', None)
namecity2 = add_source('city2', None)
@etc
nameotherclass1 = add_otherclass('name1', #etc)
#etc some thousands more
def add_source(name, distance):
s = model.Source.objects.get_or_create(name=name, distance=distance)[0]
s.save()
return s
def add_otherclass:
#etc
if __name__ == '__main__':
print ("Starting myapp population script...")
populate()
目前该脚本有效（大约），而且我怕更改...但是您怎么看？固定装置更好吗？为什么？有区别吗？
俗话说，如果它行得通，那就不要修复它。固定装置是较常见的方法，但使用自己的装置无害。如果您正在编写一个新的测试用例，则可能要使用固定装置，但是如果我是您，那么就顺其自然了。
如果您想要一种全自动的方法来获得结果，请考虑migration.RunPython。链接的文档包含一个完整的示例，该示例显示了正在加载的数据。显然，这将发生而./manage.py migrate无需其他步骤。
使用migrations.RunPython的优势在于，如果您要与同事共享应用程序或将其安装在其他服务器上，则所需的数据将自动加载到生产服务器中，并且测试中还可以完全访问该数据。数据库。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句