我有一个项目，其中包含许多应用程序，这些应用程序既可以访问我的本地MySQL数据库（包含100个表），也可以访问几个外部MySQL和Ms SQL Server数据库（包含更多表）。所有外部表都是使用"managed=False"元数据在模型中定义的。
我最近按照StackOveflow的发行说明和其他提示等，将Django从1.6升级到1.7。
除了我的所有访问远程数据库表的应用程序之外，一切似乎都恢复了正常。下面是一个示例消息：
RuntimeError: Conflicting 'bugview_deferred_description_disposition_divisioaf59cb28117de5eb6ddfea0476dab601' models in application 'nvbugsdw': <class 'bug_metrics.models_bugs.BugView_Deferred_Description_Disposition_Divisioaf59cb28117de5eb6ddfea0476dab601'> and <class 'bug_metrics.models_bugs.BugView_Deferred_Description_Disposition_Divisioaf59cb28117de5eb6ddfea0476dab601'>.
BugView表在文件名models_bugs.py中定义如下：
class BugView(models.Model):
BugId = models.BigIntegerField(primary_key=True)
Module = models.CharField(max_length=128, null=False)
Requester = models.CharField(max_length=128, null=False)
QAEngineer = models.CharField(max_length=128, null=False)
Engineer = models.CharField(max_length=128, null=False)
RequestDate = models.DateTimeField(null=False)
ModifiedDate = models.DateTimeField(null=False)
Priority = models.CharField(max_length=50, null=False)
Severity = models.CharField(max_length=50, null=False)
Disposition = models.CharField(max_length=64, null=False)
BugAction = models.CharField(max_length=64, null=False)
Origin = models.CharField(max_length=64, null=False)
GeographicOrigin = models.CharField(max_length=128, null=False)
Division = models.CharField(max_length=64, null=False)
Synopsis = models.CharField(max_length=256, null=False)
Description = models.CharField(max_length=1024, null=False)
BugType = models.CharField(max_length=50, null=False)
OriginalBugId = models.BigIntegerField()
class Meta:
app_label = 'nvbugsdw'
managed = False
db_table = 'bugview'
在views.py文件中，类被导入为：
from .models_bugs import BugView
我也试过
from models_bugs import BugView
from bug_metrics.models_bugs import BugView
"bug_metrics"是应用程序名称。
我遵循了之前在上发布的所有建议https://code.djangoproject.com/ticket/22280没有效果。
在这一点上我不知所措。有什么建议吗？
此外，这可能与此无关，但在尝试调试此问题时（通过在manage.py中转储sys.path），我注意到当我运行命令时，manage.py的代码被执行了两次
./manage.py runserver --nothreading 0.0.0.0:8081
我的系统路径是：
/opt/graphic_tools/gtools
/usr/local/lib/python2.7/dist-packages/South-0.8.4-py2.7.egg
/usr/lib/python2.7
/usr/lib/python2.7/plat-linux2
/usr/lib/python2.7/lib-tk
/usr/lib/python2.7/lib-old
/usr/lib/python2.7/lib-dynload
/usr/local/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages/PIL
/usr/lib/python2.7/dist-packages/gst-0.10
/usr/lib/python2.7/dist-packages/gtk-2.0
/usr/lib/pymodules/python2.7
/usr/lib/python2.7/dist-packages/ubuntu-sso-client
/usr/lib/python2.7/dist-packages/ubuntuone-client
/usr/lib/python2.7/dist-packages/ubuntuone-control-panel
/usr/lib/python2.7/dist-packages/ubuntuone-couch
/usr/lib/python2.7/dist-packages/ubuntuone-installer
/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol
"/opt/graphic_tools/gtools"是我的项目目录。它不包含init.py文件，并且包含所有应用程序子目录，包括"gtools"子目录。
一个建议。在升级到Django的新版本后，您是否尝试同步您的"远程"数据库？也许它们没有同步？
我想你有这样的东西：数据库=｛
"默认"：｛一些凭据｝，
"remote_db_name1"：｛一些凭据｝，
"remote_db_name2"：｛一些凭据｝，…
}
你可以运行
/manage.py migrate--database=remote_db_name1
/manage.py migrate--database=remote_db_name2
等等。（此外，我假设您以前为应用程序运行过"makemigrations"。）
原因是默认情况下migrate在"default"数据库上运行，因此其他数据库可能会被跳过。
所以，在我的特殊情况下，问题是由运行旧版本的Django引起的。我以为我安装了1.7.11，但实际上安装了1.7.0。当我安装1.7.11时，问题就消失了。
错误的方式：
sudo pip install django=="1.7"
正确方式：
sudo pip install django=="1.7.11"