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 implemented
> 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 implemented:
> subclassing an existing model and explicitly telling Django that this is
> onl
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 my
> 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 o
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 differe
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 exclusivel
> Indeed. If two applications each rely on different QuerySet classes,
> something more fine-grained than a global setting will be needed for
> them to peaceably coexist; I'd much prefer some standardized way of
> extending the functionality, something we already have to an extent
> via the abilit
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
> incompa
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 I
> 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.
>
> That
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] <[EMAIL
Some background: After following along with that whole discussion
about aggregate support, the idea struck me that the same types of
discussions were had before with schema evolution, and nobody could
really agree on much. Now that management commands are possible,
schema evolution is able to be
12 matches
Mail list logo
