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

Use lazy evaluated ForeignKey references to prevent future problems #155

Merged
merged 1 commit into from
Nov 5, 2014

Conversation

MarkusH
Copy link
Contributor

@MarkusH MarkusH commented Oct 30, 2014

Starting with Django 1.7 there have been multiple people hitting #django
with problems that eventually could be solved using lazy references to
related models instead of class references. Teaching it this ways seems
to be a good way to prevent future issues.

Starting with Django 1.7 there have been multiple people hitting #django
with problems that eventually could be solved using lazy references to
related models instead of class references. Teaching it this ways seems
to be a good way to prevent future issues.
@MattBlack85
Copy link
Contributor

I'm just curious about this issue, could you provide some more details about this problem? Also is still the same using settings.AUTH_USER_MODEL?

@MarkusH
Copy link
Contributor Author

MarkusH commented Nov 3, 2014

The problem, as far as I understand it, is that under some, relatively rare, conditions models are imported twice which screws up some internal references in Django, even though the new app loading in 1.7 should prevent that.

settings.AUTH_USER_MODEL already is a string: 'auth.User'. In order to not make the tutorial too complex at this point, I directly wrote the string representation and not a settings variable there.

Last but not least, the string representation in the form app_label.model_name works always, while the class references don't work if you refer to a model that is defined somewhere below:

class ModelA(models.Model):
    fk = models.ForeignKey('someapp.ModelB')

class ModelB(models.Model):
    fk = models.ForeignKey('someapp.ModelA')

The foreign key definition in ModelB could of course point to ModelA.

@olasitarska
Copy link
Member

Thanks Markus! ❤️

olasitarska added a commit that referenced this pull request Nov 5, 2014
Use lazy evaluated ForeignKey references to prevent future problems
@olasitarska olasitarska merged commit f371d52 into DjangoGirls:master Nov 5, 2014
@MarkusH MarkusH deleted the lazy-fk-reference branch November 7, 2014 23:36
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.

3 participants