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.
Related
I have deployed my project to Heroku and currently trying to load the data dump from local sqlite database to the Heroku database. The remote database is clean and untouched other than the initial migrate command.
I have tried the following combinations of dump but all of them returned an error
python manage.py dumpdata --exclude contenttypes --> data.json
python manage.py dumpdata --exclude auth.permission --exclude contenttypes --indent 2 > data.json
python manage.py dumpdata --exclude auth.permission --exclude contenttypes --exclude auth.user --indent 2 > data.json
and the error is:
django.db.utils.IntegrityError: Problem installing fixture
'/app/data.json': Could not load wellsurfer.Profile(pk=6): duplicate
key value violates unique constraint "wellsurfer_profile_user_id_key"
DETAIL: Key (user_id)=(1) already exists.
i would like to post the json file here but it is about 120,000 lines. But i can provide specific portions if needed. The error clearly says the key exists but the database is clean in the beginning. Obviously, i am doing something very basic thing wrong and i hope you can point me in the right direction. I have tried recommendations that i found on Stackoverflow with no success. How to manage.py loaddata in Django
I had the same problem, and this is what worked for me
source (local sqlite)
python manage.py dumpdata --natural-foreign --indent 4 > datadump.json
(this will include everything, even the auth app / users)
destination (heroku postgres)
python manage.py migrate
python manage.py shell
>>> from django.contrib.contenttypes.models import ContentType
>>> ContentType.objects.all().delete()
>>> quit()
Finally, run following command to load the json data:
python manage.py loaddata datadump.json
(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 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
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