Comments on: Named Scopes for Django

By: Empty

Empty — Sat, 12 Sep 2009 15:10:12 +0000

Nice work. While working on Django-SQLAlchemy I also wondered why QuerySet is separate from the Manager and I believe at that time I figured out the rationale for that, but it escapes me at the moment. I like having a single manager with all the business logic scoping rules in one place.

By: Alex Gaynor

Alex Gaynor — Tue, 23 Jun 2009 17:28:41 +0000

Yep, they can be nested since the QuerySet clones it’s current class when you chain methods. I don’t believe mine will work with propeties like yours does though.

By: Jim Dalton

Jim Dalton — Tue, 23 Jun 2009 14:42:03 +0000

@Alex -Thanks for sharing that; I like what you’ve done there. I did not understand your last paragraph though (in your blog post). In what sense are you repeating yourself? It seems like your solution allows you to define your manager methods in a custom manager class and then they become part of the Queryset. Where do you have to define them again?

Also, can you nest manager methods using your approach?

@Carl – Yeah, the deferring aspect of this is really non-essential. For me, my only real goals were to be able to chain and nest custom manager methods. I actually agree with you; Alex’s method appears to be simpler and if it works cleanly it’s probably better than mine. (My solution, by the way, is a lot “simpler” than it looks. Most of the code amounts to an elegant hack to facilitate it via the @scope decorator.)

And by the way, I agree with you about Django. My instinct is that custom manager methods should be chainable just like the default QuerySet methods. Not only is this not yet a feature of Django, but I couldn’t even find much chatter about it, so I’m not holding my breath.

Well, I’ll have to give Alex’s idea a try to see if it does the trick for me. Thanks to both of you for the feedback.

By: Carl Meyer

Carl Meyer — Tue, 23 Jun 2009 14:06:35 +0000

Interesting work, but seems like it’s partially based on a misunderstanding of how Django querysets work. Django querysets are always lazy (nothing is executed until the final queryset is sliced or iterated), so all the work to “defer” calls is pointless. In that sense this gives you no advantage over plain manager methods.

It does give you the ability to chain manager methods, which is nice. But as Alex said, the simpler solution to that is to move the methods onto a custom QuerySet class which your custom Manager returns, and then also proxy the methods onto your Manager (or use his “magic manager” to keep things DRY). Though I can’t help but wonder if the fact that you have to do this at all is a design flaw in Django; seems to me like there isn’t much good reason for Manager and QuerySet to be separate classes in the first place. I wonder what it would look like to unite them…

By: Alex Gaynor

Alex Gaynor — Mon, 22 Jun 2009 21:02:11 +0000

This is ultimately very similar to something I wrote about a few months ago: http://lazypython.blogspot.com/2009/01/building-magic-manager.html . In the end I find the best solution is just to subclass QuerySet and proxy the methods onto my Manager by hand however.