Just a quick thought: you should check out the work done for allowing use of
manager methods in querysets (thread "RFC: query methods"). It seems that work
does have some overlap with this feature. The patch for #3871 implements
.manager('manager_name') for reverse relation managers, and there was some
discussion for allowing .use_manager('manager_name') for querymethods.
.use_manager() is not going to be in the query methods patch. I haven't looked
#3871 in detail, but maybe the work done for query methods would make the #3871
patch easier to implement?
The idea would be to issue: .use_manager(wanted_manager).all() in the
.manager() method. The first method call would change the base manager to use,
the second (.all) call would make it return a queryset, so that you would not
have the .clear and .remove methods available. This might be a stupid idea, but
maybe worth a try? The .use_manager() call would not need to exist on queryset
level.
1.4 is feature frozen if I am not mistaken, so this would be 1.5 stuff.
- Anssi
________________________________________
From: [email protected] [[email protected]]
On Behalf Of Sebastian Goll [[email protected]]
Sent: Saturday, January 14, 2012 21:35
To: [email protected]
Subject: Re: Custom managers in reverse relations
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 <[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
