On Fri, Jun 1, 2012 at 2:26 AM, Russell Keith-Magee
<[email protected]> wrote:
> On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck <[email protected]> wrote:
...
>> Candidate.context('site') would return a manager depending on the
>> requested context.
>> (or perhaps Candidate.objects.using(context='site')... or
>> Candidate.objects.context('site'))
>>
>> # get an instance while assigning ._state.context == 'site', similar
>> to ._state.db
>> candidate_with_unpublished_races = Candidate.context('site')
...
> Is this really something that's going to be able to be managed at the
> routing level? It seems to me that the decision about exactly which
> set of objects you want returned needs much finer control that a
> router method will allow.
>
...
> Here's a counter-proposal:
>
...
> * race.candidates.all() would use _default_manager
>
> * race.candidates('objects_all').all() would use the objects_all manager
>
> * race.candidates('objects').all() would also use _default_manager
> (but explicitly)
OK, the problem I'm trying to address is "stickiness" of purpose.
Unless we have well-known names, the admin app couldn't know to use
Main.related_name(context_name).all on its inline lookups.
The thought was that
class EventAdmin(Admin):
def queryset(self):
return self.model.objects('admin')
would result in an event instance whose person_set descriptor would
continue returning objects as useful for admin, without needing to
know to call event.person_set('admin') and so on. I think well-known
names would lead to composability problems between apps.
I felt that putting it in the router nicely paralleled db_for_read in
the sense that the instance.save method writes to the ._state.db from
which the instance was received, or asks db_for_write if no such DB is
known. This continues the idea of db aliases, where the alias name is
abstract and the behavior of that name is centralized into the router.
In your objection, yes, I'm saying that a race gotten through
Race.objects.context('admin') (or Race.object('admin') if you prefer
to spell it that way) would have a .candidates which returns for the
'admin' context, whatever that means, unless told otherwise. The
implicit contract right now is that it returns 'default'. If you
wanted candidates outside of the 'admin' subset, you probably didn't
want to get a race through that context.
In any case, I understand your concern that the router approach might
not be flexible enough for general purposes, but I have a specific
purpose of needing "sticky" behavior in related lookups in a similar
manner to ._state.db does currently.
If you can see what I'm driving at, can you see a way to integrate
addressing the "sticky" need with your approach?
--
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.
