You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The semantics behind circular foreign key dependencies get kind of unwieldy when you have more than a few models (and they're spread over multiple files). This is because the DeferredRelation object has to be defined, used, then the other model defined in another file, then set_model has to be called on the original, and then you're left with the object reference dangling around that has no purpose. IE the example in the docs:
# Create a reference object to stand in for our as-yet-undefined Tweet model.DeferredTweet=DeferredRelation()
classUser(Model):
username=CharField()
# Tweet has not been defined yet so use the deferred reference.favorite_tweet=ForeignKeyField(DeferredTweet, null=True)
classTweet(Model):
message=TextField()
user=ForeignKeyField(User, related_name='tweets')
# Now that Tweet is defined, we can initialize the reference.DeferredTweet.set_model(Tweet)
It would be better if it all happened in the model definition with an optional parameter given to DeferredRelation. Like:
classUser(Model):
username=CharField()
# Tweet has not been defined yet so use the deferred reference.favorite_tweet=ForeignKeyField(DeferredRelation('Tweet'), null=True)
classTweet(Model):
message=TextField()
user=ForeignKeyField(User, related_name='tweets')
This would remove the need for the extra variable in the global namespace and the coordination of it over multiple files. And since the parameter is optional, it can be fully backwards-compatible with the old syntax.
Thank you!
The text was updated successfully, but these errors were encountered:
That's a very nice API. Depending on the class name (a string) is something I try to shy away from, as errors can occur despite the code appearing to be perfectly valid, for instance a typo or you happen to change the model name in one place and not the other.
I like the API, though, and agree that it would be worth supporting if done in a backwards-compatible way. Thanks for the patch, looking at it now.
The semantics behind circular foreign key dependencies get kind of unwieldy when you have more than a few models (and they're spread over multiple files). This is because the
DeferredRelation
object has to be defined, used, then the other model defined in another file, thenset_model
has to be called on the original, and then you're left with the object reference dangling around that has no purpose. IE the example in the docs:It would be better if it all happened in the model definition with an optional parameter given to
DeferredRelation
. Like:This would remove the need for the extra variable in the global namespace and the coordination of it over multiple files. And since the parameter is optional, it can be fully backwards-compatible with the old syntax.
Thank you!
The text was updated successfully, but these errors were encountered: