Tiny step for #38 - adds user app and creates a custom User model.
This is ideally something you would do when you create the project, so making this migration on an existing database is a bit more tricky.
It's easier to migrate to this intermediate version now, and then update to a future version that will add more authentication functionality. That's because this version does not actually change the database; we only need the migration history to fit with what Django expects based on the models.
Instructions for migration:
Check out this branch.
In PostgresQL, connect to the application database and run truncate table django_migrations;. This will remove the migration history saved in psql.
In the backend, activate your Python environment, and run yarn django migrate --fake. This will fill the django_migrations table, without actually running the migrations.
Tiny step for #38 - adds
user
app and creates a customUser
model.This is ideally something you would do when you create the project, so making this migration on an existing database is a bit more tricky.
It's easier to migrate to this intermediate version now, and then update to a future version that will add more authentication functionality. That's because this version does not actually change the database; we only need the migration history to fit with what Django expects based on the models.
Instructions for migration:
truncate table django_migrations;
. This will remove the migration history saved in psql.yarn django migrate --fake
. This will fill thedjango_migrations
table, without actually running the migrations.