Django 从另一个应用程序模型中的外键导入错误
我在此处关注了这篇文章，并整理了如何将一个模型的外键设置为另一个应用程序中的模型。然而，当我第二次尝试时，我收到一个错误，但不知道为什么。
我有一个带有“项目”和“注释”模型的中央应用程序，以及一个带有报告模型的报告应用程序。 “注释”在报告应用程序中具有指向“报告”的 FK，这似乎与以下代码配合得很好：
#models.py for Central app
from GIanno.pt_reports.models import Report
class annotation(models.Model):
...
report=models.ForeignKey(Report)
但是，在报告应用程序中，当我尝试为“报告”设置 FK 以将其链接到时使用与上面相同的格式从“中央”应用程序中获取“项目”，我收到错误“无法从导入行导入名称“项目”。
关于为什么它以一种方式而不是另一种方式工作的任何想法。顺序是否重要？ 谢谢
I followed this post here and sorted out how to set the ForeignKey of one model to a model in another application. However, when I try it a second time I get an error and not sure why.
I have Central app with models for a 'project' and an 'annotation', and a Reports app with a report model. An 'annotation' has a FK to a 'report' in the Reports app, and that seems to work fine with this code:
#models.py for Central app
from GIanno.pt_reports.models import Report
class annotation(models.Model):
...
report=models.ForeignKey(Report)
But, in the Reports app, when I try to set a FK for the 'report' to link it to a 'project' from the 'Central' app using the same format as above, I get an error "cannot import name 'project' from the import line.
Any ideas on why it works one way and not the other. Does order somehow matter? Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的猜测是您创建了循环导入条件。当您从一个 python 模块导入某些内容时，该模块又从尝试导入它的模块导入，从而阻止导入解析，就会发生这种情况。
一般来说，处理循环导入有三种策略，其中两种在这种情况下有效：
移动你的类和导入，以便导入仅向一个方向移动。
使用惰性求值。在 Django 的情况下，这可以通过使用点表示法传递指定应用程序名称和模型的字符串来完成外键：
report=models.ForeignKey('central.Report')移动 import 语句超出全局模块范围并进入模块内函数的范围。这样，导入不会立即进行评估，并且模块可以作为一个整体成功导入，同时仍然允许在调用模块时在模块内进行导入。 （注意：这不适用于外键关系）
惰性 FK 解析（#2）可能是您最好的选择。一般来说，最好的策略是简化模型/模块的排列，以尽可能避免循环导入。
My guess is that you have created a circular import condition. This occurs when you import something from one python module which in turns imports from the module which is trying to import it, thus preventing the import from ever resolving.
In general there are three strategies for dealing with circular imports, two of which will work in this case:
Move around your classes and imports so that the imports only go one direction.
Use lazy evaluation. In Django's case this can be accomplished for a ForeignKey by passing a string specifying the app name and model using dot notation:
report=models.ForeignKey('central.Report')Move the import statement out of the global module scope and into the scope of a function within the module. That way the import isn't evaluated immediately and the module can be successfully imported as a whole while still allowing the import within the module to happen when it's called. (Note: this won't work for ForeignKey relationships)
The lazy FK resolution (#2) is probably your best bet here. In general, though the best strategy is to simplify your model/module arrangement to avoid circular imports whenever possible.
尝试：
将“centralapp”替换为您的中央应用程序名称，无需导入。
惰性关系Try:
Replace 'centralapp' with name of your central app name without needing to import.
Lazy Relationships惰性关系可能有用的另一个场景是导入顺序。这不是循环引用（无法区分谁是第一个），而是一段代码先于另一段代码加载的情况。
例如，假设我有一个文档模型和一个日志模型。日志模型具有文档的 FK，因此我可以记录文档中的更改。这工作得很好，直到我尝试在我的文档模型的保存方法中生成日志记录（以创建保存事件日志条目）。在本例中，Doc 对象中没有 Log PK，但存在类似的问题。
在这种情况下，您会遇到导入顺序问题，即尝试引用尚未加载到 Python 中的内容。它与循环引用类似，但原因不同。
这可以通过其他方式解决，但这是您会遇到此问题的另一个示例。
Another scenario where the Lazy Relationships might be useful is with import order. It's not a circular reference (where it can't tell who's first) but a case where one piece of code is loaded before the other can be.
For example, let's say I have a Doc Model and a Log Model. The Log model has a FK for the Doc so I can record changes in the document. This works fine until, let's say, I try to generate a Log record in my save method for my Doc model (to make a save event log entry). There is no Log PK in the Doc object in this case but is a similar issue.
In this case you get an import order problem, where one will try to reference something that has not been loaded into Python yet. It's similar to a Circular Reference but a different cause.
This can be solved other ways but is another example where you will run into this problem.