On Thu, 2007-03-15 at 21:17 +0000, Jeff Forcier wrote:
[...]
> The problem is that QuerySets are not Managers, and so I will find
> myself mucking with these objects in various spots and not knowing
> offhand whether a given relationship attribute has e.g. the .all()
> method, or not. If it's a regular Manager, and I want the entire set,
> I must do myobj.relateditem_set.all(). If it's one of my custom
> methods, that syntax will break as QuerySets do not have .all().
>
> All I really want is the ability to have these extra faux-Manager
> methods and for them to be indistinguishable in normal usage from the
> real Managers. Any ideas? I'm unsure if it's wise to give QuerySets
> a .all() method that simply returns 'self', although that would bring
> the two object types closer together interface-wise.
It's not an insane idea. Certainly worth thinking about.
In the interim, you can work around this for your own purposes by
shoving an all() method into the QuerySet just before you return it from
each of your methods. Adds two lines of code each time, but doesn't
require touching the Django source. I'm thinking about something like:
queryset = .... # whatever magic is required
queryset.all = lambda self: return self
return queryset
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
