I have app(example) and there is only one migrations. And I have changed it and I want to unapply and apply it again. If there are many migrations and I want to unapply 0002 migrations, I would use:
django-admin migrate example 0001
but question is how can I unapply first migration?
You can pass 'zero' to unapply all of the migrations for an app.
./manage.py migrate example zero
You can see the docs here https://docs.djangoproject.com/en/2.0/ref/django-admin/#migrate
use zero
django-admin migrate example zero
in the doc
Use the name zero to unapply all migrations for an app.
You can do it by
./manage.py migrate <app> zero
Related
(I am aware that a number of Django users have had the same issue.
I have looked at a number of solutions online but none has worked for me so far.)
I have set up my apps.py, settings.py and models.py files as explained in Django official tutorial (please see the 3 files below).
When I enter in the terminal:
$ python3 manage.py makemigrations munichliving_app
It returns:
No changes detected in app 'munichliving_app'
(file settings.py) in INSTALLED_APP --> I added and tested both one at a time:
'munichliving_app' and
'munichliving_app.apps.MunichLivingConfig'
apps.py file: https://pastebin.com/raw/qaYy1x44
setting.py file: https://pastebin.com/raw/cSsbfPsx
models.py: https://pastebin.com/raw/U0QeM16k
Django official tutorial states that I should see something along the lines of:
Migrations for 'polls':
polls/migrations/0001_initial.py:
- Create model Choice
- Create model Question
- Add field question to choice
Thank you.
Your app is munichliving (the module that contains models.py), but you have munichliving_app in your INSTALLED_APPS setting. The munichlivin_app is the project folder (the one that contains settings.py). It doesn't normally contain models so you shouldn't usually have to add it to INSTALLED_APPS or make migrations for it.
Replace 'munichliving_app' with 'munichliving' in your INSTALLED_APPS.
Next, I would remove your apps.py because it doesn't appear to be used. If you do keep it, then change it to name='munichliving', then use'munichliving.apps.MunichLivingConfig'inINSTALLED_APPS`.
Finally, create migrations with
./manage.py makemigrations munichliving
Try this:
python manage.py migrate --fake appname
Or delete the migration folder in your app, go to the database and delete the file in django_migrations table, then migrate again:
python manage.py makemigrations
python manage.py migrate
I'm trying to work with django_cities_light and have followed the docs to a T and also referenced some other SO questions but no data is being imported.
When I open a python shell and do
from cities_light.models import City
c1 = City.objects.get(id=100)
c1 returns
cities_light.models.City.DoesNotExist
I've ran
./manage.py migrate
./manage.py cities_light
But there is still no data.
settings.py
CITIES_LIGHT_TRANSLATION_LANGUAGES = ['en']
CITIES_LIGHT_INCLUDE_COUNTRIES = ['FR']
CITIES_LIGHT_INCLUDE_CITY_TYPES = ['PPL', 'PPLA', 'PPLA2', 'PPLA3', 'PPLA4', 'PPLC', 'PPLF', 'PPLG', 'PPLL', 'PPLR', 'PPLS', 'STLMT',
Does anyone have an idea of how I can fix this?
think i the way:
1.rollback all migration for the app
./manage.py migrate cities_light zero
next aplpy it again
./manage.py migrate
and try to do force import
./manage.py cities_light --force-import-all
may be the last command can be enough
I have a django app called Locations and in its models.py there are 2 models:
class City(models.Model):
...
class Country(models.Model):
...
I did python manage.py schemamigration Locations --initial and then python manage.py migrate Locations. Everything worked fine.
Then I added 2 fields to City and did python manage.py schemamigration Locations --auto and it said:
Deleted field cover_image on Locations.Country
Added field lng on Locations.City
Added field ltd on Locations.City
Created 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.py. You can now apply this migration with: ./manage.py migrate Locations
Then when I did python manage.py migrate Locations, I got:
Running migrations for Locations:
- Migrating forwards to 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.
> Locations:0001_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE "Locations_country" ("id" serial NOT NULL PRIMARY KEY, "name" varchar(100) NOT NULL UNIQUE, "slug" varchar(50) NOT NULL, "image" varchar(100) NOT NULL, "flag" varchar(100) NOT NULL)
The error was: relation "Locations_country" already exists
Error in migration: Locations:0001_initial
DatabaseError: relation "Locations_country" already exists
I always keep getting this error. Am I doing something wrong?
Then I did python manage.py migrate Locations 0003 --fake and this was the output:
- Soft matched migration 0003 to 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.
Running migrations for Locations:
- Migrating forwards to 0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit.
> Locations:0001_initial
(faked)
> Locations:0002_auto__add_field_city_lng__add_field_city_ltd
(faked)
> Locations:0002_auto__add_location__add_field_country_cover_image
(faked)
> Locations:0003_auto__del_field_country_cover_image__add_field_city_lng__add_field_cit
(faked)
Now when I do python manage.py migrate Locations it says:
Running migrations for Locations:
- Nothing to migrate.
- Loading initial data for Locations.
Installed 0 object(s) from 0 fixture(s)
And those 2 fields have not been added. Whats going on? Whats the correct way to add/delete fields?
I have read the basic South documentation, please point to me if I have missed out something.
Thanks.
Delete 0002 and 0003 migrations files. And then roll back to 0001 by doing:
python manage.py migrate Locations 0001 --fake --delete-ghost-migrations
After that run schemamigration and migrate normally.
(During discussion with OP it was first cleared that 0002 and 0003 was never reflected to database, so it is no harm to delete those migration files from disk)
I have a blank MySQL database that I've just created. south is in my INSTALLED_APPS.
I run:
$ ./manage.py syncdb
...
Creating table some_app_table
You just installed Django's auth system, which means you don't have any superusers defined.
...
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
Synced:
> django.contrib.auth
> django.contrib.contenttypes
...
Not synced (use migrations):
- myapp
...
$ ./manage.py schemamigration myapp --initial
+ Added model myapp.Model
...
Created 0003_initial.py. You can now apply this migration with: ./manage.py migrate myapp
$ ./manage.py migrate myapp
Running migrations for myapp:
- Migrating forwards to 0003_initial.
> skan:0001_initial
> skan:0002_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE `myapp_model` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `user_id` integer NULL, `name` varchar(200) NOT NULL);
The error was: (1050, "Table 'myapp_model' already exists")
What's going on? Why won't South initialise correctly?
You already have some migrations defined: initial is (as expected) only needed for the initial migration.
Your syncdb output says:
Not synced (use migrations):
- myapp
Which indicates that south is working as expected. But, then you do:
$ ./manage.py schemamigration myapp --initial
+ Added model myapp.Model
...
Created 0003_initial.py. You can now apply this migration with: ./manage.py migrate myapp
Notice the 0003-prefix: this (most likely) indicates that there are already migrations defined. This is confirmed by the output of your next command:
$ ./manage.py migrate myapp
Running migrations for myapp:
- Migrating forwards to 0003_initial.
> skan:0001_initial
> skan:0002_initial
<snip>
In other words, you already have a couple of initial migrations, of which at least one will create that table. Your #3 migration tries this again, but fails, because the table of course exists by now.
What you need to do is only use initial on the creation of your Django app. As soon as the migrations folder contains a file called 0001_initial.py, you don't need any initial migrations anymore. If you change your table from this point on, call it with auto, and then migrate:
./manage.py schemamigration myapp --auto
./manage.py migrate myapp
In Django-South:
I changed I've run the initial migration successfully for myapp but for some reason, after I've made a change to my model and go to
./manage.py schemamigration myapp --auto
./manage.py migrate myapp
And I get a lot of traceback which ends in:
(1050, "Table 'my_table' already exists")
After much googling, I found and tried this:
./manage.py migrate myapp --fake
And then I proceed to migrate it, to no avail; same error.
Any suggestions?
I just got this same error, and found this question by search.
My problem was that my second migration I'd created using the --initial flag, i.e.
$ ./manage.py startapp foo
$ ./manage.py schemamigration --initial foo
$ ./manage.py migrate foo
... make some changes to foo ...
$ ./manage.py schemamigration --initial foo
(oops!)
$ ./manage.py migrate foo
... and I get the error, and the migration fails because in the second migration, South is trying to create a table its already created.
Solution
In my migrations folder:
$ ls foo/migrations
0001_initial.py 0002_initial.py
remove that second migration and re-export the second migration with the correct --auto flag:
$ rm foo/migrations/0002_initial.py
$ ./manage.py schemamigration --auto foo
$ ./manage.py migrate foo
Success!
There may be other things that cause this error, but that was my bad!
Is it an existing app?
In that case you will need to convert it in addition to the fake bit.
There are good docs here on converting an existing app.
Although they are quite tricky to find if you don't know where they are already ( ;
For converting, after adding south to your installed apps:
./manage.py syncdb
./manage.py convert_to_south myapp
./manage.py migrate myapp 0001 --fake
this problem actually happens if one of the cases:
1) You made "schemamigration app_name --initial" after one is "--auto"
2) You interrupted the last migration you have made.
To resolve such problem you apply the following:
1) mark your last schema migration as fake.
python manage.py schemamigration app_name --fake
Note: Make sure that the schema of models is same as schema of tables in database.
2) apply the migration again by doing
python manage.py schemamigration app_Name --auto
python manage.py migrate app-Name
Note: sometimes you might add manually a specific field you already added using the following syntax.
python manage.py schemamigration app_name --add-field My_model.added_field
For more info. regarding south, you could check its documentation here.