Adrian Holovaty wrote:
This would further simplify things by making a Manager's methods
*return* QuerySets instead of having a Manager *be* a QuerySet. The
downside is it's slightly more typing to do Person.objects.all() than
Person.objects -- but that's the only downside I see. Thoughts?
.a
On 1/28/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> As Robert pointed out before, you usually don't have to worry about
> resetting the cache, since the objects will get GC after the template
> and views stop using them. However, the Article.objects manager is
> special, since it is rooted in a c
> We had this discussion a while back; the goal is to separate
> "instance-level" functionality from "table-level" functionality.
> Anything that doesn't explicitly act on a model instance goes in the
> manager. With that in mind, I'm not sure having Manager subclass
> QuerySet (and making it a de
On 1/26/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> On 1/26/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > Yeah -- I'm not 100% comfortable with coupling object instances to a
> > manager. It seems a bit wonky...
>
> I'll grant that the mechanism of using the 'default' manager for the
