I have a simple model User that simply extends the AbstractUser class with some extra fields. I tried adding "objects = UserQuerySet.as_manager() but is giving me an error "get_by_natural_key() is not defined" when i try to create a superuser. It seems that it is overwriting the regular user manager so i am losing the methods that it comes with. I tried renaming the objects field to something else so I wouldnt be overwriting the default one but it still the same error. Is there any way to simply add querysets without creating whole new manager class, extending the BaseUserManager, adding all of the default methods from scratch, and adding my custom queryset to it? I just want to keep the regular UserManager and just add querysets.
class UserQuerySet(QuerySet):
def more_ten(self):
return self.filter(points__gt=10)
class User(AbstractUser):
points = IntegerField(default=0)
tester = UserQuerySet.as_manager()
#objects = UserQuerySet.as_manager()
According to the docs, your custom user manager should inherit from BaseUserManager
class UserQuerySet(QuerySet):
def more_ten(self):
return self.filter(points__gt=10)
from django.contrib.auth.models import UserManager as OldUserManager
class UserManager(OldUserManager):
def get_queryset(self):
return UserQuerySet(model=self.model, using=self._db, hints=self._hints)
class User(AbstractUser):
objects = UserManager()
Related
given the following situation:
models.py
from .managers import PersonManager
from django.db import models
class Person(models.Model):
first_name = models.CharField(max_length=256)
last_name = models.CharField(max_length=256)
managers.py
from .models import Person
from django.db import managers
class PersonManager(models.Manager):
def create(self, person_dict):
new_person = Person(
first_name=person_dict['first_name']
last_name=person_dict['last_name'])
new_person.save()
How can I write my model manager to avoid circular import?
It is actually not working, my guess is that I would have to create my object inside my manager without refering to it as class Person, instead I should use a more general generic Django name. Any thoughts?
There are a few options here.
Firstly, you could define the model and the manager in the same file; Python has no requirement or expectation that each class is in its own file.
Secondly, you don't actually need to import the model into the manager. Managers belong to models, not the other way round; from within the manager, you can refer to the model class via self.model.
And finally, if that's all your manager is doing, there is no reason for it at all. Managers already have a create method; it takes keyword parameters, rather than a dict, but that just means you can call it with Person.objects.create(**person_dict).
I have a QuerySet in a view like the following. I would like to be able to use the same query in other views, but I don't want to have to copy and paste the code. This also feels like I would be violating the DRY principal.
If I would like to modify the query at a later date, I would have to change it in all my views, which clearly isn't ideal. Is there a class I should create or a method in my model which would let me call this from many different views? Are there any best practices concerning this?
tasks = Task.objects.filter(user = request.user).order_by('-created_at', 'is_complete')
One of the solutions would be to create a classmethod on the model or extending model's manager.
from django.db import models
Adding classmethod
class MyModel(models.Model):
#classmethod
def get_user_tasks(cls, user):
return cls.objects.filter(...).order_by(...)
Overriding manager
class MyModelManager(models.Manager):
def get_user_tasks(self, user):
return self.filter(...).order_by(...)
class MyModel(models.Model):
objects = MyModelManager()
# and in the view...
queryset = MyModel.objects.get_user_tasks(request.user)
I want my models to have order field, which will contain order of an item among all items of its kind.
And I want to use choices within that IntegerField, which would contain all the numbers of currently existing items in that table.
So it would need to be dynamic choices.
How do I load all existing "order" values of all existing items in a table, and use this list for choices?
It sounds like you want to build a manager for your model:
models.py
from django.db import models
class OrderManager(models.Manager):
def order_choices(self):
return [(i, i) for i in OrderModel.objects.values_list('order', flat=True)]
class OrderModel(models.Model):
objects = OrderManager()
order = models.IntegerField()
class Meta:
ordering = ['order']
def __unicode__(self):
return '%i' % self.order
forms.py
from django import forms
from yourapp.models import OrderModel
class OrderModelForm(forms.ModelForm):
order = forms.ChoiceField(choices=OrderModel.objects.order_choices())
class Meta:
model = OrderModel
admin.py
from django.contrib import admin
from yourapp.forms import OrderModelForm
from yourapp.models import OrderModel
class OrderModelAdmin(admin.ModelAdmin):
form = OrderModelForm
admin.site.register(OrderModel, OrderModelAdmin)
Edit
Managers are use to make general model queries without having an instance of a model object. If you don't understand the concept of managers, you can still refactor the code out of the manager class, stick it somewhere else and import that function across your code. Managers allow you to abstract custom general queryset that you can reuse. See more details https://docs.djangoproject.com/en/dev/topics/db/managers/
The code without the manager will look like
views.py or some other file
from app.models import OrderModel
def order_choices():
return [(i, i) for i in OrderModel.objects.values_list('order', flat=True)]
From anywhere in your code, if you want to reuse the above multiple times:
from app.views import oder_choices
order_choices()
as opposed to:
from app.models import OderModel
OrderModel.objects.order_choices()
If you only want to use the above once, you can leave it in the forms.py as shown in the other answer. It's really up to you on how you want to refactor your code.
Dont add the choices directly to the model, add them to a form represnting the model later, by overriding the field with a set of choices.
than, do something like:
class MyForm(..):
myfield_order_field = IntegerField(choices = [(i,i) for range(MyModel.objects.count)])
class Meta():
model = MyModel
if you want to use it in the admin, add to your Admin Class:
class MyModelAdmin(admin.ModelAdmin):
...
form = MyForm
it will override this field in the admin too.
I am having trouble getting my model manager to behave correctly when using the Admin interface. Basically, I have two models:
class Employee(models.Model):
objects = models.EmployeeManager()
username = models.CharField(max_length=45, primary_key=True)
. . .
class Eotm(models.Model): #Employee of the Month
date = models.DateField()
employee = models.ForeignKey(Employee)
. . .
And I have an EmployeeManager class that overrides the get() method, something like this:
class EmployeeManager(models.Manager):
use_for_related_fields = True
def get(self, *arguments, **keywords):
try:
return super(EmployeeManager, self).get(*arguments, **keywords)
except self.model.DoesNotExist:
#If there is no Employee matching query, try an LDAP lookup and create
#a model instance for the result, if there is one.
Basically, the idea is to have Employee objects automatically created from the information in Active Directory if they don't already exist in the database. This works well from my application code, but when I tried to create a Django admin page for the Eotm model, things weren't so nice. I replaced the default widget for ForeignKey fields with a TextInput widget so users could type a username (since username is the primary key). In theory, this should call EmployeeManager.get(username='whatever'), which would either return an Employee just like the default manager or create one and return it if one didn't already exist. The problem is, my manager is not being used.
I can't find anything in the Django documentation about using custom Manager classes and the Admin site, aside from the generic manager documentation. I did find a blog entry that talked about specifying a custom manager for ModelAdmin classes, but that doesn't really help because I don't want to change the model represented by a ModelAdmin class, but one to which it is related.
I may not be understanding what you're trying to do here, but you could use a custom Form for your Eotm model:
#admin.py
from forms import EotmAdminForm
class EotmAdmin(models.ModelAdmin):
form = EotmAdminForm
#forms.py
from django import forms
from models import Eotm, Employee
class EotmAdminForm(forms.ModelForm)
class Meta:
model = Eotm
def clean_employee(self):
username = self.cleaned_data['employee']
return Employee.get(username=username)
That, in theory, should work. I haven't tested it.
I have a model that has a ForeignKey to the built-in user model in django.contrib.auth and I'm frustrated by the fact the select box in the admin always sorts by the user's primary key.
I'd much rather have it sort by username alphabetically, and while it's my instinct not to want to fiddle with the innards of Django, I can't seem to find a simpler way to reorder the users.
The most straightforward way I can think of would be to dip into my Django install and add
ordering = ('username',)
to the Meta class of the User model.
Is there some kind of monkeypatching that I could do or any other less invasive way to modify the ordering of the User model?
Alternatively, can anyone thing of anything that could break by making this change?
There is a way using ModelAdmin objects to specify your own form. By specifying your own form, you have complete control over the form's composition and validation.
Say that the model which has an FK to User is Foo.
Your myapp/models.py might look like this:
from django.db import models
from django.contrib.auth.models import User
class Foo(models.Model):
user = models.ForeignKey(User)
some_val = models.IntegerField()
You would then create a myapp/admin.py file containing something like this:
from django.contrib.auth.models import User
from django import forms
from django.contrib import admin
class FooAdminForm(forms.ModelForm):
user = forms.ModelChoiceField(queryset=User.objects.order_by('username'))
class Meta:
model = Foo
class FooAdmin(admin.ModelAdmin):
form = FooAdminForm
admin.site.register(Foo, FooAdmin)
Once you've done this, the <select> dropdown will order the user objects according to username. No need to worry about to other fields on Foo... you only need to specify the overrides in your FooAdminForm class. Unfortunately, you'll need to provide this custom form definition for every model having an FK to User that you wish to present in the admin site.
Jarret's answer above should actually read:
from django.contrib.auth.models import User
from django.contrib import admin
from django import forms
from yourapp.models import Foo
class FooAdminForm(forms.ModelForm):
class Meta:
model = Foo
def __init__(self, *args, **kwds):
super(FooAdminForm, self).__init__(*args, **kwds)
self.fields['user'].queryset = User.objects.order_by(...)
class FooAdmin(admin.ModelAdmin):
# other stuff here
form = FooAdminForm
admin.site.register(Foo, FooAdmin)
so the queryset gets re-evaluated each time you create the form, as opposed to once, when the module containing the form is imported.