I have model Foo which resides inside app bar. Now, I wish to move thmodel to app bar2. I am already using db_table when syncdb with bar before
meta:
db_table = 'foo_table'
Now when I do schemamigration with bar, south wants me to delete the table. Is there any ways I can avoid this (table name foo_table is still the same despite changing the app) without manually editing the migration file?
if no changes in database, then you can create empty migrations for both apps in which was this model and which now has this model:
./manage.py schemamigration app1 del_model1 --empty
./manage.py schemamigration app2 add_model1 --empty
south analyze models which described in last migration and on this data he create next migrations
Related
I am following these two references (one and two) to have a custom user model in order to authenticate via email and also to add an extra field to it.
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(
unique=True,
max_length=254,
)
mobile_number = models.IntegerField(unique=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
objects = UserManager()
...
...
class Meta:
db_table = 'auth_user'
...
...
As you can see, I have added the db_table='auth_user' into the Meta fields of the class. Also, I have included AUTH_USER_MODEL = 'accounts.User' and User model app (i.e., accounts)into the INSTALLED_APPS in settings.py. Further more, I deleted the migrations folder from the app.
Then tried migrating:
$ python manage.py makemigrations accounts
Migrations for 'accounts':
accounts/migrations/0001_initial.py:
- Create model User
$ python manage.py migrate accounts
Which gives me an error:
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency accounts.0001_initial on database 'default'.
How can I migrate from the existing django user model into a custom user model?
You have to clear admin, auth, contenttypes, and sessions from the migration history and also drop the tables. First, remove the migration folders of your apps and then type the following:
python manage.py migrate admin zero
python manage.py migrate auth zero
python manage.py migrate contenttypes zero
python manage.py migrate sessions zero
Afterwards, you can run makemigrations accounts and migrate accounts.
The solution is to undo your existing migrations that depend on AUTH_USER_MODEL as mentioned in this answer. In case you are trying to undo migrations for admin, auth, contenttypes and sessions and you get an error like:
ERRORS:
auth.User.groups: (fields.E304) Reverse accessor for 'User.groups' clashes with reverse accessor for 'Profile.groups'.
....
First of all comment out/undo AUTH_USER_MODEL in settings.py if you had changed that.
Secondly comment out/undo your django app that contains new AUTH_MODEL from INSTALLED_APPS in settings.py.
Now you should be able to undo migrations for auth, admin, contenttypes and sessions as:
python manage.py migrate admin zero
python manage.py migrate auth zero
python manage.py migrate contenttypes zero
python manage.py migrate sessions zero
Now add your auth model app to INSTALLED_APPS and set AUTH_USER_MODEL in your settings.py again.
Run: python manage.py migrate AUTH_APP, you may need to make migrations for your auth model app as well: python manage.py makemigrations AUTH_APP
Apply all migrations that you undo by: python manage.py migrate.
You are all done.
Note: You will lose all existing users present in database.
As in my particular case, the other answers did not help (the error still occured even after I tried to drop the tables with migrate ... zero and even after I deleted the migrations folder), the following helped, but I was at the very beginning and therefore it was no problem to just delete the db.sqlite3 file which is created whenever you migrate the first time. (Depending on your settings.py you might have a different database-file).
You really can only do this if you are sure that you don't lose important data from your database file (e.g. you do not yet have much information stored in the database and it is not difficult to start over again), and you will need to migrate everything again.
Delete the existing all the tables from data base.[Note : data will be lost]
Delete pycache and migrations from all the apps.
Run migrations for your relative app
python manage.py makemigrations users
Migrate the tables to database
python manage.py migrate
You need to run:
python manage.py makemigrations accounts
Before executing the initial manage.py migrate (by initial I mean at the very first time you run migrate on your project)
it is recommended to set up your custom User model at the start of your project so you'll have the "accounts" app migrated at the same time as the admin,auth,contenttypes,sessions tables are created.
but if you have created your tables already, then you should follow the instructions as #krishna-chandak described: https://stackoverflow.com/a/53599345/5950111
you can read the docs : https://docs.djangoproject.com/en/2.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project
There's a django_migrations table in your database after your previous migration which is the cause of this inconsistency.
Solution: Deleting the django_migrations table from your database.
delete the migration folder from your apps
and then perform
python3 manage.py makemigrations
python3 manage.py migrate
I know it's rather an old question, but for people googling this topic like me today, here is a solution without deleting migrations, dropping the tables, and other nasty stuff)
https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
I also had the same problem. I followed the steps:
In models.py, i setup basic User model
# accounts/models.py
class User(AbstractBaseUser):
class Meta:
db_table = 'auth_user'
Then, i ran makemigrations command to generate migration file
$ python manage.py makemigrations accounts
Migrations for 'accounts':
accounts/migrations/0001_initial.py:
- Create model User
Next step, i inserted record has 0001_initial todjango_migrations table
$ echo "INSERT INTO django_migrations (app, name, applied) VALUES ('accounts', '0001_initial', CURRENT_TIMESTAMP);" | python manage.py dbshell
Update lastest in model
# accounts/models.py
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(
unique=True,
max_length=254,
)
mobile_number = models.IntegerField(unique=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
objects = UserManager()
...
...
class Meta:
db_table = 'auth_user'
...
...
I need makemigrations again
After run makemigrations, i had the next migration file.
0002_....py
Migrate agains
python manage.py migrate.
What worked for me was a solution that I pieced togeather from all the diffretent solutions given here.
I check if the database exists since I don't have an issue with an existing database, only when the database is empty.
# check if the database exists
db_ok=false
if python ./manage.py check; then
db_ok=true
fi
if [ $db_ok = true ]; then
# database exists: do a normal migrate
python ./manage.py migrate
else
# database does not exists, make and migrate users then a migrate and cleanup of the users migraton
python ./manage.py makemigrations users
python ./manage.py migrate users
python ./manage.py migrate
rm -r users/migrations/
fi
I had similar problem, where I have to introduce the custom user model in the middle of the project. So following steps helped me to solve the issue without table drop or data loss.
(1) Create an initial empty migration for the app ('accounts')
python manage.py makemigrations accounts --empty
(2) Run migrate
python manage.py migrate
(3) Update the timestamp in the django_migrations table in the database , for 'accounts' initial migration to the 'admin' initial timestamp.
UPDATE django_migrations SET applied=<<admin 0001_initial date>> WHERE app='accounts' and name='0001_initial';
(4) Now create your Custom User model (derived from AbstractUser) with out any fields, and set the table name to auth_user. You are basically re-using the existing auth user table in database.
class User(AbstractUser):
class Meta:
db_table = 'auth_user'
(4) Now run migration, and copy the migration to 0001_initial and remove '0001_initial' from the dependency array. Also remove the newly created migration file.
python manage.py makemigrations accounts
cp accounts/migrations/0002_user.py accounts/migrations/0001_initial.py
edit the file 0001_initial.py
rm accounts/migrations/0002_user.py (remove migration file)
(5) Now add your custom fields, run makemigrations and migrate as usual.
Migrate zeroing didn't help me. I had to drop the whole database:
sudo -u postgres psql
drop database YOURDATABASENAME;
create database YOURDATABASENAME;
Then:
python ./manage.py makemigrations MYAPPNAME
python ./manage.py migrate MYAPPNAME
python ./manage.py migrate
And after these I got forward..
I am following these two references (one and two) to have a custom user model in order to authenticate via email and also to add an extra field to it.
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(
unique=True,
max_length=254,
)
mobile_number = models.IntegerField(unique=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
objects = UserManager()
...
...
class Meta:
db_table = 'auth_user'
...
...
As you can see, I have added the db_table='auth_user' into the Meta fields of the class. Also, I have included AUTH_USER_MODEL = 'accounts.User' and User model app (i.e., accounts)into the INSTALLED_APPS in settings.py. Further more, I deleted the migrations folder from the app.
Then tried migrating:
$ python manage.py makemigrations accounts
Migrations for 'accounts':
accounts/migrations/0001_initial.py:
- Create model User
$ python manage.py migrate accounts
Which gives me an error:
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency accounts.0001_initial on database 'default'.
How can I migrate from the existing django user model into a custom user model?
You have to clear admin, auth, contenttypes, and sessions from the migration history and also drop the tables. First, remove the migration folders of your apps and then type the following:
python manage.py migrate admin zero
python manage.py migrate auth zero
python manage.py migrate contenttypes zero
python manage.py migrate sessions zero
Afterwards, you can run makemigrations accounts and migrate accounts.
The solution is to undo your existing migrations that depend on AUTH_USER_MODEL as mentioned in this answer. In case you are trying to undo migrations for admin, auth, contenttypes and sessions and you get an error like:
ERRORS:
auth.User.groups: (fields.E304) Reverse accessor for 'User.groups' clashes with reverse accessor for 'Profile.groups'.
....
First of all comment out/undo AUTH_USER_MODEL in settings.py if you had changed that.
Secondly comment out/undo your django app that contains new AUTH_MODEL from INSTALLED_APPS in settings.py.
Now you should be able to undo migrations for auth, admin, contenttypes and sessions as:
python manage.py migrate admin zero
python manage.py migrate auth zero
python manage.py migrate contenttypes zero
python manage.py migrate sessions zero
Now add your auth model app to INSTALLED_APPS and set AUTH_USER_MODEL in your settings.py again.
Run: python manage.py migrate AUTH_APP, you may need to make migrations for your auth model app as well: python manage.py makemigrations AUTH_APP
Apply all migrations that you undo by: python manage.py migrate.
You are all done.
Note: You will lose all existing users present in database.
As in my particular case, the other answers did not help (the error still occured even after I tried to drop the tables with migrate ... zero and even after I deleted the migrations folder), the following helped, but I was at the very beginning and therefore it was no problem to just delete the db.sqlite3 file which is created whenever you migrate the first time. (Depending on your settings.py you might have a different database-file).
You really can only do this if you are sure that you don't lose important data from your database file (e.g. you do not yet have much information stored in the database and it is not difficult to start over again), and you will need to migrate everything again.
Delete the existing all the tables from data base.[Note : data will be lost]
Delete pycache and migrations from all the apps.
Run migrations for your relative app
python manage.py makemigrations users
Migrate the tables to database
python manage.py migrate
You need to run:
python manage.py makemigrations accounts
Before executing the initial manage.py migrate (by initial I mean at the very first time you run migrate on your project)
it is recommended to set up your custom User model at the start of your project so you'll have the "accounts" app migrated at the same time as the admin,auth,contenttypes,sessions tables are created.
but if you have created your tables already, then you should follow the instructions as #krishna-chandak described: https://stackoverflow.com/a/53599345/5950111
you can read the docs : https://docs.djangoproject.com/en/2.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project
There's a django_migrations table in your database after your previous migration which is the cause of this inconsistency.
Solution: Deleting the django_migrations table from your database.
delete the migration folder from your apps
and then perform
python3 manage.py makemigrations
python3 manage.py migrate
I know it's rather an old question, but for people googling this topic like me today, here is a solution without deleting migrations, dropping the tables, and other nasty stuff)
https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/
I also had the same problem. I followed the steps:
In models.py, i setup basic User model
# accounts/models.py
class User(AbstractBaseUser):
class Meta:
db_table = 'auth_user'
Then, i ran makemigrations command to generate migration file
$ python manage.py makemigrations accounts
Migrations for 'accounts':
accounts/migrations/0001_initial.py:
- Create model User
Next step, i inserted record has 0001_initial todjango_migrations table
$ echo "INSERT INTO django_migrations (app, name, applied) VALUES ('accounts', '0001_initial', CURRENT_TIMESTAMP);" | python manage.py dbshell
Update lastest in model
# accounts/models.py
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(
unique=True,
max_length=254,
)
mobile_number = models.IntegerField(unique=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
objects = UserManager()
...
...
class Meta:
db_table = 'auth_user'
...
...
I need makemigrations again
After run makemigrations, i had the next migration file.
0002_....py
Migrate agains
python manage.py migrate.
What worked for me was a solution that I pieced togeather from all the diffretent solutions given here.
I check if the database exists since I don't have an issue with an existing database, only when the database is empty.
# check if the database exists
db_ok=false
if python ./manage.py check; then
db_ok=true
fi
if [ $db_ok = true ]; then
# database exists: do a normal migrate
python ./manage.py migrate
else
# database does not exists, make and migrate users then a migrate and cleanup of the users migraton
python ./manage.py makemigrations users
python ./manage.py migrate users
python ./manage.py migrate
rm -r users/migrations/
fi
I had similar problem, where I have to introduce the custom user model in the middle of the project. So following steps helped me to solve the issue without table drop or data loss.
(1) Create an initial empty migration for the app ('accounts')
python manage.py makemigrations accounts --empty
(2) Run migrate
python manage.py migrate
(3) Update the timestamp in the django_migrations table in the database , for 'accounts' initial migration to the 'admin' initial timestamp.
UPDATE django_migrations SET applied=<<admin 0001_initial date>> WHERE app='accounts' and name='0001_initial';
(4) Now create your Custom User model (derived from AbstractUser) with out any fields, and set the table name to auth_user. You are basically re-using the existing auth user table in database.
class User(AbstractUser):
class Meta:
db_table = 'auth_user'
(4) Now run migration, and copy the migration to 0001_initial and remove '0001_initial' from the dependency array. Also remove the newly created migration file.
python manage.py makemigrations accounts
cp accounts/migrations/0002_user.py accounts/migrations/0001_initial.py
edit the file 0001_initial.py
rm accounts/migrations/0002_user.py (remove migration file)
(5) Now add your custom fields, run makemigrations and migrate as usual.
Migrate zeroing didn't help me. I had to drop the whole database:
sudo -u postgres psql
drop database YOURDATABASENAME;
create database YOURDATABASENAME;
Then:
python ./manage.py makemigrations MYAPPNAME
python ./manage.py migrate MYAPPNAME
python ./manage.py migrate
And after these I got forward..
When I use manage.py makemigrations <app> only columns with relations are migrated to pg database.
How to instruct django to migrate new basic non-relational columns, like:
title = models.CharField(max_length=20, null=True)
I'm using django 1.8.2. on Ubuntu
No fields at all are being migrated when you run manage.py makemigrations <app>, as that command only creates a new migration in your <app>/migrations/ directory. It's only when you run manage.py migrate that changes are written to the database.
If you are not getting the expected results, have a look at the newest migration and determine which fields it affects. All fields should be targeted by migrations, not relational fields only. Changing properties like max_length, blank, required etc. should trigger migrations. If they don't it's probably because your changes doesn't require any database schema modification.
If you are still having problems, please post:
Your models prior to model change
Your models after model change
The migration generated by makemigrations
Previously I had a django model like this
class Review(models.Model):
reviewdate=models.DateField(default=date.today)
description=models.TextField()
author=models.ForeignKey(User,null=True)
I have some 500 records of Review in db.
I added a field to model
from django.core.validators import MinValueValidator,MaxValueValidator
class Review(models.Model):
reviewdate=models.DateField(default=date.today)
description=models.TextField()
author=models.ForeignKey(User,null=True)
rating= models.IntegerField(validators=[MinValueValidator(1), MaxValueValidator(10)], default=5, help_text='integers 1 to 10')
I ran python manage.py schemamigration myapp --auto successfully ,which created a 0002_auto__add_field_review_rating.py file
Now, I need to do the datamigration for the existing records in db. Do I have to run
python manage.py datamigration myapp somechanges
and then implement the functions in the created somechanges.py ? Since I have already defined in the new field difficulty a default value of 5, will that not be taken when migrate command is run? Do I have to explicitly set it in the somechanges.py functions?
You do not need to do a data migration for this case. As you have specified a default for your new field, that will be used when you apply the schema migration.
Use the following command to apply the migration:
./manage.py migrate myapp
See the advanced changes South tutorial for more information on default values for new fields.
I have a model like this
class Task(models.Model):
name = models.CharField(max_length=100)
...
class TaskForm(forms.ModelForm):
class Meta:
model = Task
Then,I added couple of fields to Task and did migration
python manage.py schemamigration myapp --initial
python manage.py migrate myapp
Migration is successfully done.
Now,as an afterthought,I added a help_text to the model field
class Task(models.Model):
name = models.CharField(max_length=100,help_text='choose a good one')
...
Do I have to do the schemamigration again?I think his change doesn't affect the database table.
You need not run migrate again.
Django do not save help_text to the databases, help_text exists in application level, Django render it to HTML.