The QuerySet method examples [1] mostly use the corresponding Manager
proxy method.
Probably QuerySet.create() exists to use querysets where managers are
expected.
An ugly corner case:
cat.article_set.filter(...).create(title=title)
is equivalent to
Article.objects.create(title=title)
Am 16.06.2008 um 20:56 schrieb James Bennett:
> It'd also hurt the reusability of managers (which is a big advantage I
> and others have taken advantage of), because you wouldn't be able to
> keep methods specific to a single model separate from methods which
> aren't, at least not without
True. But surprisingly enough, the `create` method is a QuerySet
instance method. And it doesn't use any of the filtering, so
Article.objects.filter(category=cat).create(title=title,
content=content)
doesn't do what you'd expect. (Though `cat.article_set.create` should
work.) Has that
> So then what is the difference between a Manager and a QuerySet?
>
> Nearly everything would work identically if Manager were simply:
>
> class Manager(QuerySet):
> pass
>
> (except actually keeping the magic that connects it to the model
> class.)
Utility methods in managers wouldn't make
On Mon, Jun 16, 2008 at 1:48 PM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> You could as stick them in a single manager as well (and wouldn't
> have to remember which method is available via which manager).
> My point is that one manager per model would be enough to do anything
> you can do
Am 16.06.2008 um 18:49 schrieb James Bennett:
>
> On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>> If you're just want different querysets you can use something like
>> this: http://dpaste.com/53948/.
>
> Or I can use managers and also add other supporting
So then what is the difference between a Manager and a QuerySet?
Nearly everything would work identically if Manager were simply:
class Manager(QuerySet):
pass
(except actually keeping the magic that connects it to the model
class.)
It would be exactly identical, except that:
* the
On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> If you're just want different querysets you can use something like
> this: http://dpaste.com/53948/.
Or I can use managers and also add other supporting methods (which I
also often do).
--
"Bureaucrat Conrad, you
If you're just want different querysets you can use something like
this: http://dpaste.com/53948/.
Things.live.all() vs Things.objects.live().
Am 16.06.2008 um 16:37 schrieb James Bennett:
>
> On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
> <[EMAIL PROTECTED]> wrote:
>> Is there a
On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Is there a rationale for multiple managers per model?
Yes, and I at least use them all the time. For example, I'll often
have one manager that does no special filtering, and another that only
returns things with a
Second try. I promise there won't be a third.
Is there a rationale for multiple managers per model? Or is it a
that's-how-it's-always-been thing?
If I missed something obvious, I would have received a "wrong list or
rtfm" reply by now, supposedly.
{{{
class AManager(Manager):
pass
11 matches
Mail list logo
