On 04/18/2011 02:59 PM, Carl Meyer wrote:
Hmm. Why does it make sense for OneToOneField lookups to behave differently from *_set managers? If I've got a default manager that hides "deleted" objects, for instance: why should deleted objects by default "not exist" when I traverse a reverse FK, but "exist" when I traverse a OneToOneField?
OK, may be not reverse OneToOne… What I mean is that although it seems natural to treat all relations equally they are actually used for different use cases where different defaults make sense. For example:
- Reverse many-to-one (topic.article_set) access is used to access a (limited) list of children which is expected to behave as any other list of such objects and hence should use the default manager.
- Direct one-to-one or many-to-one (article.topic or profile.user) access is used to access a parent object and in most real cases it doesn't make sense if it's absent for example. Usually you're just dealing with a "deleted" child accessing its "deleted" parent which is OK. In this case it makes sense to use a pure manager to build the relation.
As for reverse one-to-one I'm really not sure because I can't recall any real example to lay upon. Speaking about documentation simplicity (which directly influences sanity of its readers) it can be made as simple as that:
- pure manager is used whenever there is a clear child-parent realation (direct OneToOne and ForeignKey access)
- all other relations use default managers - explicit use_for_related_fields overrides default behavior What do you think? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
