On 04/19/2011 01:47 AM, Ivan Sagalaev wrote:
> OK, may be not reverse OneToOne… What I mean is that although it seems
> natural to treat all relations equally they are actually used for
> different use cases where different defaults make sense. For example:
>
> - Reverse many-to-one
On 04/19/2011 04:58 AM, Johannes Dollinger wrote:
>> Do you have real-world use-cases in mind that require per-relation
>> manager configuration? I can't think of any uses I've run across
>> that weren't workable with a single default manager used by all
>> relations.
>
> The only time I used a
On 04/18/2011 02:59 PM, Carl Meyer wrote:
Hmm. Why does it make sense for OneToOneField lookups to behave
differently from *_set managers? If I've got a default manager that
hides "deleted" objects, for instance: why should deleted objects by
default "not exist" when I traverse a reverse FK, but
Hi Johannes,
On 04/18/2011 01:45 PM, Johannes Dollinger wrote:
> Deprecate `use_for_related_fields` and always use the default manager
> for related managers. Then add the possibility to specify custom
> mangers for individual relations:
>
> ForeignKey(Foo, related_manager=RSpecialManager)
On 04/18/2011 04:35 PM, Ivan Sagalaev wrote:
> Not exactly… I mean that when use_for_related_fields is set explicitly
> Django should respect it. Right now, as I understand from your first
> mail, it doesn't work as False when set to False. So I agree that this
> should definitely be fixed.
>
>
On 04/18/2011 11:45 AM, Johannes Dollinger wrote:
I'd vote for (C).
Deprecate `use_for_related_fields` and always use the default manager for
related managers. Then add the possibility to specify custom mangers for
individual relations:
ForeignKey(Foo, related_manager=RSpecialManager)
On 04/18/2011 11:16 AM, Carl Meyer wrote:
By "just this" I presume you actually mean just the second half of what
you quoted ("explicitly set to False")? In other words, you're proposing
to make use_for_related_fields work as advertised, but make it default
to True instead of False?
Not
Am 17.04.2011 um 01:30 schrieb Carl Meyer:
> So - do we (A) fix the behavior to match our documented semantics, note
> it in the release notes, and hope for the best? Or (B) bow to
> backwards-compatibility and change the documentation to match the actual
> behavior? Or (C) find some middle
On 04/18/2011 12:47 PM, Luke Plant wrote:
>> So - do we (A) fix the behavior to match our documented semantics, note
>> it in the release notes, and hope for the best? Or (B) bow to
>> backwards-compatibility and change the documentation to match the actual
>> behavior? Or (C) find some middle
Hi Ivan,
On 04/18/2011 01:07 PM, Ivan Sagalaev wrote:
>> even if "use_for_related_fields" is absent or explicitly set to
>> False on your Manager subclass.
>
> … the default manager should not be used as a base class. Fixing just
> this would be the best option because it retains current
On 04/16/2011 04:30 PM, Carl Meyer wrote:
in general, related-object access for
reverse-FKs and M2Ms, contrary to the documentation, will _always_ use
your default manager (actually, a dynamic subclass of it)
It kind of makes sense. You don't want your deleted items to appear in
results just
On 17/04/11 00:30, Carl Meyer wrote:
> So - do we (A) fix the behavior to match our documented semantics, note
> it in the release notes, and hope for the best? Or (B) bow to
> backwards-compatibility and change the documentation to match the actual
> behavior? Or (C) find some middle ground (a
Hi all,
Our documentation on "automatic managers" [1] and related managers [2]
is quite clear that automatically-created managers for related-objects
access will be plain-vanilla Manager instances, unless you set
"use_for_related_fields = True" on the custom Manager subclass that you
use as a
13 matches
Mail list logo
