Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid importing models in models #106

Closed
wants to merge 2 commits into from

Conversation

funkybob
Copy link
Contributor

Use lazy relation resolution for ForeignKey fields
Use django.db.models.get_model or django.apps.apps.get_model to get ContentType model in model methods.

Use string for for lazy resolution
Use apps.get_model (or models.get_model) for other cases.
django.apps.apps is an object, not a module.
@zhang-z
Copy link
Contributor

zhang-z commented Dec 21, 2015

@funkybob , thank you for the contribution.

I know lazy relation resolution is needed to avoid circular model imports in some cases. But importing models also has a benefit that if you use IDE's (e.g. Pycharm) refactoring feature to rename a model, the direct importing works better. In our case, circular model imports doesn't exist because notification app imports Django's builtin app while the reversed import won't happen. So is there any general discussion on why lazy relation resolution is preferred over importing models?

@funkybob
Copy link
Contributor Author

Personally, I always use lazy references, but I don't use PyCharm, so don't know its limitations. However, I do agree a good discussion on the benefits is warranted, so have opened one on the django-developers mailing list.

I'm quite sure I was driven to that change to prevent app state not ready errors when migrating a project from 1.4 to 1.9... I will verify tomorrow.

@zhang-z
Copy link
Contributor

zhang-z commented Dec 23, 2015

@funkybob , thanks for opening the discussion. Let me paste the link here.

@zhang-z
Copy link
Contributor

zhang-z commented Dec 31, 2015

@funkybob , from the mailing list discussion, seems no more benefits of string FK references have been revealed, other than solving circular relations when needed. On the other side, regular FK references may help IDE to detect typos and dependencies. Do you think we can close this pull request until find more findings to support string FK references?

@funkybob funkybob closed this Jan 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants