On Jun 2, 7:57 am, Russell Keith-Magee
wrote:
> Apologies for the long and rambling answer; I hope it's shed some
> light on the source of my concern. To be clear -- I'm not completely
> opposed to your idea of 'stickiness', and I can see how it might be
> useful -- I've just got concerns about th
On Jun 2, 6:53 am, Russell Keith-Magee
wrote:
> I might be missing something in the details here, but are you
> proposing here that even though there's only one FK reverse relation
> from Event to Person, there would be 2 attributes (events and
> confirmed_events) containing lists? That doesn't st
On Sat, Jun 2, 2012 at 1:54 AM, Jeremy Dunck wrote:
> On Fri, Jun 1, 2012 at 2:26 AM, Russell Keith-Magee
> wrote:
>> On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck wrote:
> ...
>>> Candidate.context('site') would return a manager depending on the
>>> requested context.
>>> (or perhaps Candidate.o
On Fri, Jun 1, 2012 at 7:08 PM, Anssi Kääriäinen
wrote:
> On Jun 1, 1:43 pm, Russell Keith-Magee
> wrote:
>> > Just as a bike-shedding thought: Would it be possible to have
>> > frank.events.confirmed.all() as the syntax? I see this a tiny bit
>> > cleaner. On the other hand it isn't explicit you
On Fri, Jun 1, 2012 at 7:28 PM, Sebastian Goll wrote:
> On Fri, 1 Jun 2012 17:26:54 +0800
> Russell Keith-Magee wrote:
>
>> Here's a counter-proposal: (…)
>>
>> So, using your example:
>>
>> * race.candidates.all() would use _default_manager
>>
>> * race.candidates('objects_all').all() would us
On Fri, Jun 1, 2012 at 2:26 AM, Russell Keith-Magee
wrote:
> On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck wrote:
...
>> Candidate.context('site') would return a manager depending on the
>> requested context.
>> (or perhaps Candidate.objects.using(context='site')... or
>> Candidate.objects.context
On Fri, 1 Jun 2012 17:26:54 +0800
Russell Keith-Magee wrote:
> Here's a counter-proposal: (…)
>
> So, using your example:
>
> * race.candidates.all() would use _default_manager
>
> * race.candidates('objects_all').all() would use the objects_all manager
>
> * race.candidates('objects').all
On Jun 1, 1:43 pm, Russell Keith-Magee
wrote:
> > Just as a bike-shedding thought: Would it be possible to have
> > frank.events.confirmed.all() as the syntax? I see this a tiny bit
> > cleaner. On the other hand it isn't explicit you can only use
> > the .confirmed only directly after the events,
On Fri, Jun 1, 2012 at 5:54 PM, Anssi Kääriäinen
wrote:
> On Jun 1, 12:26 pm, Russell Keith-Magee
> wrote:
>> 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
On Jun 1, 12:26 pm, Russell Keith-Magee
wrote:
> 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.
>
> It might n
On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck wrote:
> It feels to me that each place that ._default_manager is mentioned
> here is a misfeature:
> https://github.com/django/django/blob/2cd516002d43cdc09741618f0a0db047ee6d78fd/django/db/models/fields/related.py
>
> As an example, we (Votizen) curre
It feels to me that each place that ._default_manager is mentioned
here is a misfeature:
https://github.com/django/django/blob/2cd516002d43cdc09741618f0a0db047ee6d78fd/django/db/models/fields/related.py
As an example, we (Votizen) currently have some default managers which
show subsets of all obje
12 matches
Mail list logo
