At the moment it's very easy to add methods to individual models, just
by putting a method on the model class itself which accepts 'self'.
However, defining business logic on collections of records is
currently pretty complicated — you have to create at least a custom
Manager subclass, and if you w
On Tue, Jan 3, 2012 at 1:55 PM, Zachary Voase wrote:
> At the moment it's very easy to add methods to individual models, just
> by putting a method on the model class itself which accepts 'self'.
> However, defining business logic on collections of records is
> currently pretty complicated — you h
On Jan 3, 7:01 am, Russell Keith-Magee
wrote:
> On Tue, Jan 3, 2012 at 1:55 PM, Zachary Voase wrote:
> > At the moment it's very easy to add methods to individual models, just
> > by putting a method on the model class itself which accepts 'self'.
> > However, defining business logic on collectio
I replied to the ticket, but I'll mention it here as well. django-model-utils
has an implementation of something
that achieves the same result. It was originally from
http://paulm.us/post/3717466639/passthroughmanager-for-django
and has since been added to https://github.com/carljm/django-model
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Zachary,
On 01/02/2012 10:55 PM, Zachary Voase wrote:
> At the moment it's very easy to add methods to individual models, just
> by putting a method on the model class itself which accepts 'self'.
> However, defining business logic on collections o
On Tue, Jan 3, 2012 at 11:43 AM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Zachary,
>
> On 01/02/2012 10:55 PM, Zachary Voase wrote:
> > At the moment it's very easy to add methods to individual models, just
> > by putting a method on the model class itself which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/2012 10:42 AM, Alex Gaynor wrote:
> I haven't analyzed your suggestion in detail Carl, but there is a good
> reason for managers to exist:
> querysets cache internally on iteration, managers are not directly
> evaluable, but were they you cou
I have had difficulty in finding an easy way to add common methods to
querysets and managers for multiple models in Django.
I solved the problem in my projects by defining a custom `Manager`
class which defines `use_for_related_fields = True` and also overrides
`__getattr__()` to look for queryset
Tai, we use that same structure at my work and so far it has worked well.
https://github.com/fusionbox/django-fusionbox/blob/master/fusionbox/db/models.py
It also extends well. You can define queryset methods elsewhere and then
inherit from them on multiple models to reuse those methods easily.
Forgive me if I am missing something --- I use custom managers extensively
and do not see what your code can do that the django custom managers can't
? Can you provide an example please ?
On Tue, Jan 3, 2012 at 12:55 AM, Zachary Voase wrote:
> At the moment it's very easy to add methods to indi
On Fri, Jan 6, 2012 at 12:02 AM, Daniel Sokolowski
wrote:
> Forgive me if I am missing something --- I use custom managers extensively
> and do not see what your code can do that the django custom managers can't ?
> Can you provide an example please ?
Zachary provided a complete example in his or
On Jan 3, 7:55 am, Zachary Voase wrote:
> At the moment it's very easy to add methods to individual models, just
> by putting a method on the model class itself which accepts 'self'.
> However, defining business logic on collections of records is
> currently pretty complicated — you have to create
On Jan 9, 10:51 pm, Anssi Kääriäinen wrote:
> I have a very quickly crafted draft of the main idea
> athttps://github.com/akaariai/django/compare/dynamic_man
>
> As you can see, the implementation is very simple. It is missing
> manager autodiscovery, and the @querymethod decorator.
>
> I have
It should be relatively simple to allow QuerySets to know which
manager they came from, and then override __getattr__ to use the
declared @querymethod from that manager (instead of the other way
around). This avoids the unpickleable QuerySet subclass problem.
On Jan 10, 8:54 am, Anssi Kääriäinen
On Jan 10, 12:19 pm, Zachary Voase wrote:
> It should be relatively simple to allow QuerySets to know which
> manager they came from, and then override __getattr__ to use the
> declared @querymethod from that manager (instead of the other way
> around). This avoids the unpickleable QuerySet subc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Anssi,
On 01/10/2012 04:14 AM, Anssi Kääriäinen wrote:
> However, I would like it if you could mix methods from different
> managers. Maybe add qs.set_manager(manager_name), and so you could do:
> SomeModel.objects.order_by('id').some_manager_metho
On Jan 10, 7:10 pm, Carl Meyer wrote:
> Having access to any manager method from any queryset, regardless of
> which manager that queryset came from, seems to me like a highly
> surprising anti-feature, not a benefit. Can you outline a realistic use
> case for it?
Basically any time when you have
I strongly feel that switching around managers like that would be an
example of overengineering.
The user story which drove this RFC was based on an issue which has
been encountered by lots of developers, but typically solved in a
single way. Django's conservative style of development is very
acco
On 01/12/2012 07:24 AM, Zachary Voase wrote:
I strongly feel that switching around managers like that would be an
example of overengineering.
The user story which drove this RFC was based on an issue which has
been encountered by lots of developers, but typically solved in a
single way. Django's
On Jan 12, 2:24 pm, Zachary Voase wrote:
> I strongly feel that switching around managers like that would be an
> example of overengineering.
I tend to over-engineer things. It is easy to add the manager
switching later on if needed. And it is easy to switch managers by
just changing qs.manager i
Got interested in this after a referral from the tricket tracker. Couldn't
this specific case be solved with a simple change to __getattr__ on
QuerySet?
def __getattr__(self, attr):
try:
qmethod = getattr(self.manager, attr).im_func
is_querymethod = qmethod.is_querymethod
21 matches
Mail list logo
