On Mon, Mar 31, 2008 at 5:27 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> If you want to be able to specify a different default manager for some
> particular use of an existing model, you're sort of after a third type
> of model subclassing that I've thought about but haven't
On Sun, 2008-03-30 at 13:31 -0700, [EMAIL PROTECTED] wrote:
> > Agreed. In fact, this exact suggestion was made during the recent
> > discussions about adding aggregates. I'd much rather see per-manager
> > customization of Query Sets, rather than a global setting.
>
> What do you think about
> Agreed. In fact, this exact suggestion was made during the recent
> discussions about adding aggregates. I'd much rather see per-manager
> customization of Query Sets, rather than a global setting.
What do you think about my latest proposal of a
get_custom_manager(MyManager) function on Model
On Sat, Mar 29, 2008 at 8:40 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Fri, Mar 28, 2008 at 5:54 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> > schema-evolution is separable from applications -- it's utility, and
> > applications codes are still compatible with each other, but
I'm -1 on this, I think the principal problem is that discourages
finding the best ways to solve the problems in django itself, one of
the main differences between django and other python web frameworks is
that Django offers it's own option at every level of the stack, and
people almost
On Fri, Mar 28, 2008 at 5:54 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> schema-evolution is separable from applications -- it's utility, and
> applications codes are still compatible with each other, but different
> querysets features as 3rd-party libraries could make project code
>
The idea of adding custom methods to QuerySets seem interesting but I
think that subclasing a core part of the framework is quite messy and
will require for the developers to know/understand the inner workings
of the framework (and there goes abstraction). With this approach you
would end up, if
> In my opinion the answer is this:
> 1. A BaseQuerySet that all internal Django calls could rely on staying
> the same.
> 2. A setting (DEFAULT_QUERYSET_CLASS for example) which, by default,
> points to BaseQuerySet, but could be changed to point to any sucblass
> of BaseQuerySet.
>
>
schema-evolution is separable from applications -- it's utility, and
applications codes are still compatible with each other, but different
querysets features as 3rd-party libraries could make project code
incompatible, and that's baaad.
On Fri, Mar 28, 2008 at 11:07 AM, [EMAIL PROTECTED]
