I'm adding a new app, and while setting up the database using South I get the following:
... line 11, in forwards
db.add_column('experiments_dailyreport', 'test_group_size',
orm['experiments.dailyreport:test_group_size'])
You cannot add a null=False column without a default value.
Given that this is a new table with no data in it, is there some way to force this migration?
You can force a migration using:
manage.py migrate --fake django-lean 0005
where 0005 is the version number of the migration. All that matters in your situation are:
having the correct database schema in the end
having South think that all migrations have been run
After that you can run the other migrations as normal. Alternatively, you can remove South, create the latest tables from django-lean using syncdb and then fake all the django-lean migrations.
Lastly, if you're certain that there's something wrong with the migration, it's worth contacting the django-lean developer(s) about this.
Related
I built an internal app that used django-safedelete. I was working fine for months, until i recently upgraded my distro, and tried to add a field to my model.
I also upgraded my python modules, everything is up-to-date, and no errors during the upgrade.
Now I cannot migrate anymore:
if I "makemigrations" I get an error message "django.db.utils.OperationalError: (1054, "Unknown column 'gestion_ltqmappsetting.deleted_by_cascade' in 'field list'")"
if I add a boolean "deleted_by_cascade" field in my ltqmappsetting table, then the "makemigration" works, but the "migrate" fails with "MySQLdb.OperationalError: (1060, "Duplicate column name 'deleted_by_cascade'")"
I tried removing the field after makemigrations, but the migrate fails with the first error message.
I also tried removing the "migration" operations in the 0087...migration.py file, but it does not have any impact.
Is there anyway to update the migration file between the makemigrations and the migrate commands ?
Thanks a lot for any help on this.
jm
It's a wonder how I can actually look for answers for hours, then post on this site, and a few minutes later, I actually find the answer ...
Anyway.
It looked like I was mistaken on the meaning of the second error message. It failed because a previous migration already create the deleted_by_cascade field in another table, not in the appsetting one.
So the steps to solve my issue where:
migrate migrate 0086 to remove the latest migrations
make sure the DB only had the deleted_by_cascade column in the appsetting table
makemigrations - this creates the 0087 migration to add deleted_by_cascade column in all tables
edit the 0087 migration to not create the new column in the appsetting table
run makemigrations once again - - this creates the 0088 migration to add deleted_by_cascade column in the appsetting table
migrate 0087
migrate --fake 0088
Et voila ...
There was probably something wrong in the safe_delete update.
Hope this can help others.
jm
I kind of know why when I do migrate it gives me the message of no migrations to apply but I just don't know how to fix it
This is what happens.
I added a new field named update into my model fields.
I did a migration which created a file called 0003_xxxxx.py then I did a migrate now this worked fine.
But then because of some reason, I have to remove the update field from the same model.
So I removed it (more likey commented instead of really delete the code) then I did migration and migrate which removed the field in db. (created 0004_xxxxx.py)
But sigh....some reason I have to add the field back again (this is why I only commented out) but then before I do the migration
I removed the 0003_xxxx.py and 0004_xxxx.py files I wanted to remove those two files because this is actually the same or almost the same config as 0003_xxxx.py so I feel it's pointless having the 0003_xxxx.py and 0004_xxxx.py here...also when I go production, that's just another extra step for python to run.
After I removed those two files, I did the migration which creates another 0003_xxxx.py but when I do migrate it gives me the message of no migrations to apply
I know that by deleting the 0003_xxxx.py and get the original 0003 and 0004 back then do another migration (creates 0005_xxxx.py) then migrate then changes will be made. I know this because I didn't really delete the original 0003 and 0004 I moved it somewhere just in case of this kind of happening.
But why is this though? and is there a way to fix it?
Thanks in advance for any replies
django keep records of current migrations log by table django_migrations in your db.
something like:
The migrations is a chain structure,it's depend on the parent node.By this table django can know which migrations file is executed.
In you case,no migrations to apply because the new create 0003_xxxx.py is record in this table,you can fix it by delete this record in this table.
If you want remove some migration file you need see Squashing migrations.
Or even simply just delete the last migration row from your database you can try the following
First, check which row you want to remove
SELECT * FROM "public"."django_migrations";
Now pick the last id from the above query and execute
DELETE FROM "public"."django_migrations" WHERE "id"=replace with your Id;
run ./manage.py migrate.
just run:
python manage.py run --run-syncdb
So I have this django installation in which there are a bunch of migration scripts. They look like so:
00001_initial.py
00002_blah_blah.py
00003_bleh_bleh.py
Now I know these are "database building" scripts which will take stuff defined in models.py and run them against the db to "create" tables and stuff.
I want to create a new table(so I created its definition in models.py). For this, I have copied another model class and edited its name and fields and it is all fine. Lets call this new model class 'boom'.
My question is now how do I "create" this boom table using the migration script and the boom model?
I am worried that I might accidentally disrupt anything that is already in DB. How do I run the migration to create only boom table? How do I create a migration script specifically for it?
I know that it has something to do with manage.py and running migrate or runmigration (or is it sqlmigrate?...im confused). While creating the boom table, I dont want the database to go boom if you know what I mean :)
First, create a backup of your database. Copy it to your development machine. Try things out on that. That way it doesn't matter if it does go "boom" for some reason.
The first thing to do is
python manage.py showmigrations
This shows all the existing migrations, and it should show that they have been applied with an [X].
Then,
python manage.py makemigrations
Makes a new migration file for your new model (name 00004_...).
Then do
python manage.py migrate
to apply it. To undo it, go back to the state of migrations 00003, with
python manage.py migrate <yourappname> 00003
There are two steps to migrations in Django.
./manage.py makemigrations
will create the migration files that you see - these describe the changes that should be made to the database.
You also need to run
./manage.py migrate
this will apply the migrations and actually run the alter table commands in SQL to change the actual database structure.
Generally adding fields or tables won't affect anything else in the database. Be more careful when altering or deleting existing fields as that can affect your data.
The reason for two steps is so that you can make changes on a dev machine and once happy commit the migration files and release to your production environment. Then you run the migrate command on your production machine to bring the production database to the same state as your dev machine (no need for makemigrations on production assuming that your databases started the same).
My question is now how do I "create" this boom table using the
migration script and the boom model?
./manage.py makemigrations
I am worried that I might accidentally disrupt anything that is
already in DB.
The whole point of migrations, is that it doesn't
I know that it has something to do with manage.py and running migrate
or runmigration
For more information please refer to : https://docs.djangoproject.com/en/1.10/topics/migrations/
And rest assured that your database will not go boom! :-)
I solved it simply, changing the name of the new model to the original name, and then I checked if there is the table in the database, if not, I just create a new table with the old name with just a field like id.
And then clear migrations and create new migrations, migrate and verify table was fixed in DB and has all missing fields.
If it still doesn't work, then change the model name back to a new one.
but when django asks you if you are renaming the model you should say NO to get the old one removed properly and create a new one.
This type of error usually occurs when you delete some table in dB manually, and then the migration history changes in the tables are lost.
But it is not necessary to erase the entire database and start from scratch.
I'm sorry if the name of the question is misleading but here is the deal.
I have dump of the database that was used with old version of django app (django < 1.7).
I have a new version of code which is using django 1.7. And now I need to upgrade some server with new code while saving all data.
How I thought it would work:
Restore database, run new migration (1.7 migrations) with ./manage.py migrate.
Done!
But when I'm running migrations I have "Relation already exists error".
I know that this is happening probably because database is out of sync with migration history or something... But I don't know what to do.
EDIT1 I sense that the only way is manually create migration script or something, because there is now way to sync database with new migrations now.
So suppose a have a table in database named TABLE and two columns C1 and C2.
Now when I was migrating from 1.6 to 1.7 I've added column C3. So the initial migration looks something like this "create table TABLE with COLUMNS C1, C2, C3".
And when I will try to migrate with old database it wouldn't be ably to do this.
Delete new columns.
Create initial migrations.
Fake initial migrations for all apps:
python manage.py migrate --fake yourappnamehere 0001
Add columns, create new migrations.
Execute new migrations.
The problem is pretty self-explanatory in the title. Do I need to do that or I just need to edit the existing migration file?
Yes, Django won't recognize the field if you change the name. I will say that the "field does not exist", so YES, you have to run Django's South migrate / schemamigration as you asked.
Datatype YES as well. Django may be okay at first if you only change the field type depending, but may run into problems later depending on what you have in that field.
You need to do a schemamigration every time you change your models.
On every call of python manage.py migrate command south record number of the latest migration applied into database migrationhistory table. So if you just change existing migration it won't be applied because south would think it's already applied.
You can make a backward migration, fix next migration, even delete it and make a new one and only then migrate forward.