Hello together,
unfortunately I am struggling with customizing the user model.
Generally said the user model fit very well to our demands, the only point is the name of the tables (we want/need to use MS SQL and to set a specific schema name we need to change the db_table property of the Meta classes).
Thus I to copy the Permission, Group, User, PermissionMixin, AbstractUser, Session, ContentType…tables in my /models.py file, adapted them (db_table of the model classes themself but also the ManyToManyFields , change the setting.py file (AUTH_USER_MODEL = ‘.MyUser’; below INSTALLED_APPS and MIDDLEWARE).
So far so good.
But when I run makemigrations there are still made migrations for/by auth:
- Permission
- Group
- User
and from contenttypes the table ContentType is created.
My question is: why are these tables are still created although I replaced them in my models.py file?
Thanks in advance!
Best regards,
Tom
Hi Tom,
These models are still being created because they exist in another django app. You would need to stop having those apps in your INSTALLED_APPS or find a way to have django use a different db_table.
If I were tackling this, I’d probably try monkey patching [Model].Meta.db_table somewhere. I’d be curious if you would need to put the replacement app before the built-in django apps in INSTALLED_APPS, so that it would change those classes before they get loaded in the model registry.
Hi Tim,
thanks for your fast response. Now I put my app (actually my project only has one app beside the “default” apps) at the top of the INSTALLED_APPS but the other tables would still be created as makemigrations --dry-run shows me:
Migrations for 'automationapp':
automationapp\migrations\0001_initial.py
...
- Create model MyContentType
- Create model MySession
...
- Create model MyPermission
- Create model MyGroup
- Create model MyUser
Migrations for 'contenttypes':
C:\Users\...\.virtualenvs\...\django\contrib\contenttypes\migrations\0001_initial.py
- Create model ContentType
Migrations for 'admin':
C:\Users\...\.virtualenvs\...\django\contrib\admin\migrations\0001_initial.py
- Create model LogEntry
Migrations for 'auth':
C:\Users\...\.virtualenvs\...\django\contrib\auth\migrations\0001_initial.py
- Create model Permission
- Create model Group
- Create model User
When I delete those apps (admin, auth, contenttypes) from the INSTALLED_APPS list, I got error messages, like:
RuntimeError: Model class django.contrib.contenttypes.models.ContentType doesn’t declare an explicit app_label and isn’t in an application in INSTALLED_APPS.
From my newbie point of of view it’s a bit sad, that customizing even only the table names produces such an overhead…but maybe it’s just because I’m a newbie 
That error makes sense. Removing the apps entirely wasn’t a great idea. Try monkey patching the properties.
Sorry for this question, but what does monkey patching mean?
After writing the below comment, I want to recommend that you don’t do this and deal with the table names as they are. I think with enough hacking you could get Django to work how you want it to, but it’s going to be an ongoing effort to keep it like that and it’ll probably get worse over time.
No need to apologize. I didn’t want to assume a level of knowledge. The short version of monkey patching is that it’s a hacky way to change behavior of code that you didn’t write. It’s not something you should do often and is a last resort. Here’s a write-up on it.
What I think you’d end up doing is in your automationapp/models.py file, you’d have something like
from django.contrib.contenttypes.models import ContentType
ContentType.Meta.db_table = "my_new_db_table"
However, that’s going to require a new migration because the model will have changed. I don’t recommend having a new migration get created within django app because eventually Django will release a new migration as a part of a version update, it’ll conflict and you’ll experience pain.