How to ignore Django.contrib.auth Migrations?

Asked

Viewed 178 times

0

I have a Django application where I intend to customise the authentication part. I’ve already made my own Backend of authentication, as well as configuring my own Model that will be used in authentication.

The problem is, when I turn the remote python manage.py showmigrations, the following Migrations are appearing:

auth
 [ ] 0001_initial
 [ ] 0002_alter_permission_name_max_length
 [ ] 0003_alter_user_email_max_length
 [ ] 0004_alter_user_username_opts
 [ ] 0005_alter_user_last_login_null
 [ ] 0006_require_contenttypes_0002
 [ ] 0007_alter_validators_add_error_messages
 [ ] 0008_alter_user_username_max_length
 [ ] 0009_alter_user_last_name_max_length
contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name
sessions
 [ ] 0001_initial

How is it possible to remove these Migrations from auth in Django? I intend to use a customised scheme and I don’t want to let denecessary tables be created.

Note: My File settings.py is configured as follows:

AUTHENTICATION_BACKENDS = ('app.backends.AuthBackend', )
AUTH_USER_MODEL = 'app.usuarios'
python django migrations

  • If you are not using any auth, you have already tried to simply remove it from INSTALLED_APPS in Settings?

  • @jsbueno actually I want to use the custom Auth. It would be a problem if I used a table with a different pattern than the one in Django auth?

  • If you delete or change the type of columns, Django’s Auth code will certainly break - what you can’t tell is whether it will only break in the functions you overide and will use yours, or whether it will break into things he will use as well. The safest would be to use other tables, which the Auth does not "see" - but extra columns should also not give problem

  • @jsbueno my intention was to make a permissions control structure using Django’s auth base, without picking up all the luggage (with the creation of a collection of tables that I saw Django create).

  • He has a good reason to create this "table top": it’s how the whole thing worked, and well, after decades of evolution. Or you expand in the recommended way: inheriting classes and placing.

1 answer

1

Before giving migrate give the following command
python manage.py migrate auth --fake

Or just give in the Migrations you don’t want to create

python manage.py migrate auth nome_da_migration --fake

But as the staff has already commented, be careful not to reinvent the wheel. Because what you are doing can affect the installation of new libs, update of the version of Django, among other problems. The best practice in this case is to extend the standard Django classes and make the modifications you need.

Browser other questions tagged python django migrations

You are not signed in. Login or sign up in order to post.