django-managers

I'm confused about the correct way to use Django custom model managers - based on the docs you can create a series of managers for one model as a way of filtering. But why not create one manager class with a series of functions for filtering? Is one method better than the other? and why? For example: class MaleManager(models.Manager): def get_query_set(self): return super(MaleManager, self).get_query_set().filter(sex='M') class FemaleManager(models.Manager): def get_query_set(self): return super(FemaleManager, self).get_query_set().filter(sex='F') class Person(models.Model): first_name =

This is a pretty simple django patterns question. My manager code usually lives in models.py, but what happens when models.py is really huge? Is there any other alternative pattern to letting your manager code live in models.py for maintainability and to avoid circular imports? A question may be asked as to why models.py is so huge, but let's just assume it's size and breadth of utility is justified. I prefer to keep my models in models.py and managers in managers.py (forms in forms.py) all within the same app. For more generic managers, I prefer to keep them in core.managers if they can be re

I was wondering if it was possible (and, if so, how) to chain together multiple managers to produce a query set that is affected by both of the individual managers. I'll explain the specific example that I'm working on: I have multiple abstract model classes that I use to provide small, specific functionality to other models. Two of these models are a DeleteMixin and a GlobalMixin. The DeleteMixin is defined as such: class DeleteMixin(models.Model): deleted = models.BooleanField(default=False) objects = DeleteManager() class Meta: abstract = True def delete(self): self.deleted = True self.save

To sum things up before I get into bad examples, et al: I'm trying to make an application where I don't have to write code in all my models to limit choices to the current logged in account (I'm not using Auth, or builtin features for the account or login). ie, I don't want to have to do something like this: class Ticket(models.Model): account = models.ForeignKey(Account) client = models.ForeignKey(Client) # A client will be owned by one account. content = models.CharField(max_length=255) class TicketForm(forms.ModelForm): class Meta: model = Ticket exclude = ('account',) #First sign of bad

I want to access the currently logged in user in a custom manager I have wrote. I want to do this so that I can filter down results to only show objects they have access to. Is there anyway of doing this without actually passing it in? Something similar to how it works in views where you can do request.user. Thanks Jack M. Without passing it in, the best way I've seen is to use a middleware (described in this StackOverflow question , I'll copy/paste for ease of reference): Middleware: try: from threading import local except ImportError: from django.utils._threading_local import local _thread

I have 2 Django models, ModelA with an ArrayField that is used to store a large list of primary key values (possibly 50k+ list) class ModelA(models.Model): pk_values = ArrayField(models.IntegerField()) class CustomManager(manager.Manager): def get_for_index(self, index_id): qs = self.get_queryset() obj = ModelA.objects.get(pk=index_id) return qs.filter(id__in=obj.pk_values) class ModelB(models.Model): # [...] some fields objects = CustomManager() This works: qs = ModelB.objects.get_for_index(index_id=1) However, this would be super slow where "pk_values" is a large list. So I tried doing raw

I have encountered with some suspicious behavior of create() method of User object manager. Looks like password field isn't required for creating User object if you use this method. In result you get User with blank password . In case when you use create_user method and don't specify password it creates User with unusable password (through to set_unusable_password() ). I am not sure why create() method doesn't raise exception when you try to create user without password - in documentation it's specified that this field is required. Is something wrong in create() method/documentation? That's

In my work we want to run a server with multiple databases. The databases switching should occur when you acces a url like http://myapp.webpage.com or http://other.webpage.com . We want to run only one server instance and at the moment of the HTTP request switch the database and return the corresponding response. We've been looking for a mantainable and 'Django-friendly' solution. In our investigation we have found possible ways to do this, but we have not enough information about. Option 1: Django middleware The django middleware runs each time the server receive a HTTP request. Making a