Hi all,
My latest post to the list seems to have been lost in the pre-Christmas
storm. Sorry for that!
The issue of picking which custom manager is used in resolving reverse
relations still stands. Let my give you an example why this is useful:
{{{
class Reporter(models.Model):
...
class Article(models.Model):
reporter = models.ForeignKey(Reporter)
...
articles = models.Manager()
published_articles = PublishedManager()
}}}
We put some thought into designing PublishedManager. Maybe it needs to
do some things in addition to simply checking a flag, who knows. The
thing is: right now, we simply cannot make use of this manager when
looking up a reporter's articles: with `reporter.article_set` we
always get _all_ articles. [1]
Now we have two options: doing the filtering manually, on the returned
queryset, or specify that we want to use PublishedManager, accessible
through the `published_articles` attribute of the Article class.
The latter is implemented by the patches in ticket #3871:
https://code.djangoproject.com/ticket/3871
Does this seem like a good idea? Should it even be possible to specify
which custom manager is used for reverse relations? Or, am I missing
something and this is already possible in some other way?
Since I'm looking forward to seeing this implementation in Django 1.4,
I ask for your input on the matter.
Thanks!
Sebastian.
[1] In fact, that's not entirely true: we get whatever is returned by
the _default_ manager of the Article class. This seems like an
arbitrary choice: it's not a "plain" manager that always returns all
related instances, it's whatever we picked as the default manager.
On Fri, 23 Dec 2011 21:56:24 +0100
Sebastian Goll <sebastian.g...@gmx.de> wrote:
> Hi all,
>
> I'd like to draw your attention to long-open ticket #3871 [1].
>
> The idea is to let ORM users choose which custom manager to use for reverse
> "many" relations, i.e. reverse foreign key (…_set) as well as forward and
> reverse many-to-many relations.
>
> There are several proposed patches to this ticket, the latest was added by me
> a week ago. The current implementation adds a "manager()" method to the
> reverse manager which allows you to pick a manager different from the default
> one on the related model. All changes are entirely backwards-compatible – if
> you don't call the "manager()" method, everything is as before, i.e. the
> default manager is used to look up related model instances.
>
>
> During my review of the previous patch I found that it doesn't apply cleanly
> to trunk, as well as some concerns with regard to the general approach of the
> implementation.
>
> Therefore, I wrote an alternative patch which is currently awaiting review.
> Since I wrote that patch, I cannot review it myself. If you can spare some
> time, maybe you can take a look at it and if you feel the current approach is
> okay, bump the ticket to "ready for check-in".
>
> Of course feel free to raise any concerns you might have.
>
> Regards,
> Sebastian.
>
> PS: Merry X-Mas and whatnot! :D
>
> [1] https://code.djangoproject.com/ticket/3871
--
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.
