On 1/26/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > It seems to me that the translation from ``sites`` in the model to > ``site_set`` in the instance is "worse" than having an inconsistency > between m2m and o2m relations. In fact, I don't really have a > problem with the two relation types behaving differently. > > I'd suggest that m2m relations use the attribute name, and that we > introduce an option for ForeignKey that lets you override the o2m name:: > > class Article: > writer = meta.ForeignKey(Reporter, related_name="articles") > sites = meta.ManyToManyField(Site) > > s = Site.objects.get(pk=1) > r = Reporter.objects.get(pk=1) > > s.article_set.all() > r.articles.all() > > That is, if ``related_name`` isn't given then ``OBJECT_set`` is used.
OK, this sounds good to me. > OK, what about this: make ``objects`` callable:: > > Before After > > Article.objects.get_list() Article.objects() > Article.objects.get_list(**kw) Article.objects(**kw) > Article.objects.get_object(**kw) Article.objects.get(**kw) > Article.objects.get_values(**kw) Article.objects.values(**kw) > > That's more concise in the common case -- I'd guess that get_list() > is far and away the most common method used -- and it does away with > the filter/all distinction. The problem with this is that Article.objects is a Manager instance, so it would be slightly ugly and special-casish to have to specify behavior for __call__(). If you wanted to override the functionality for a custom manager, you'd have to override __call__(). That's not "magic" per se, but it's still a bit of a special case. Gotta say I really like the all() and filter() explicitness. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
