django 1.7 migrate gets error "table already exists"

Question

I am trying to apply a migration but am getting the error:

django.db.utils.OperationalError: (1050, "Table 'customers_customer' already exists")

I get this by issuing the following command:

python manage.py migrate

My customer table already exists, so what do I do to let the migration know this, not error out, and run my modification to my model?

I ran this on my local environment with local database with no problem. It is when I pointed my database to production and ran migrate above that I get this error.

One question - Should you not be using the django migrations instead of south for django 1.7? — karthikr, Sep 19 '14 at 01:18
@karthikr I am using django migrations. I used a south tag on this question because I thought someone in that community might know the answer. — Atma, Sep 19 '14 at 01:55
I think I faced a similar issue. If you run python manage.py syncdb then later run the manage.py migrate, it results in that, because syncdb also kinda creates those tables. The recommend approach would be to run this, assuming you have no database: python manage.py migrate . Then if you wanna create superuser, you do python manage.py createsuperuser. — KhoPhi, Apr 25 '15 at 19:19
I have the same problem. Nothing worked so far. It seems I killed a mechanism by deleting the migration directory and database file. I thought deleting those files would be ok, to start from scratch, but apparently it is not. — Soerendip, Nov 07 '18 at 23:03

elmonkeylp · Accepted Answer · 2015-11-26T19:49:59.403

200

If you have the table created in the database, you can run

python manage.py migrate --fake <appname>

Mark migrations as run without actually running them

Or if you want to avoid some actions in your migration, you can edit the migration file under the app/migrations directory and comment the operations you don't want to do in the migrate execution.

Docs: https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south or python manage.py help migrate

edited Nov 26 '15 at 19:49

answered Sep 19 '14 at 02:17

elmonkeylp

2,674
1
16
14

^Works in Django 1.11 – Feb 12 '18 at 19:48
4

I hope no issues will come due to this – Ajay Kumar May 02 '19 at 05:57
This worked. However, part of what was in the fake was a new table to the database. To solve this, I forced another migration by adding a field to the new table. Then I edited the new migration and added the table creation in the new migration and removed the new field that I didn't need. This produced my new table and keep the migration path going. The --fake gave me something to start with. Thank you. – Anthony Petrillo May 08 '23 at 17:39

score 23 · Answer 2 · edited Oct 03 '15 at 15:25

23

Its actually python manage.py migrate --fake <appname>

edited Oct 03 '15 at 15:25

ham-sandwich

3,975
10
34
46

answered Apr 24 '15 at 08:20

Waqas Javed

743
8
18

score 11 · Answer 3 · answered Aug 08 '18 at 09:41

We can solve this issue in two way as mentioned in answer: 1.) By editing in migration file

We have migrations folder created in each application we create, In those migration folder the migration file(0001_initial.py is the initially created and after this all other files dependent on this initial file will be create), When we run the python manage.py migrate, For every APP the migration file will apply if there is change in the file. We can see this run Applying on terminal after the migrate command. If there is any issue in migration file we use to get the error at that point. In my/our case:

Applying ValetUser.0002_keyroundslots_systemparameters_vehicleparking_vehicleparkingdetails...Traceback (most recent call last):
sqlite3.OperationalError: table "valet_keyroundslots" already exists

Here we can notice that the file in which we have issue is mentioned i.e ValetUser.0002_keyroundslots_systemparameters, So we can Go to the App and then migrations and in 0002 file we can Comment the CreateModel Operation of That particular Model in which we are facing issue while applying migrations. example:

operations = [
    # migrations.CreateModel(
    #     name='KeyRoundSlots',
    #     fields=[
    #         ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
    #         ('key_round', models.IntegerField()),
    #         ('key_slot', models.IntegerField()),
    #         ('is_available', models.BooleanField()),
    #         ('Valet_id', models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.CASCADE, related_name='valet_location', to='ValetUser.ValetAt')),
    #     ],
    #     options={
    #         'db_table': 'valet_keyroundslots',
    #     },
    # ),

2.) By applying fake migration of the modified migration file of the particular APP in which we are facing the error/issue, --fake will apply the fake migration that will not effect to the already applied migration of the model.

python manage.py migrate --fake <appname>

The answers given Waqas and elmonkeylp are also right, I just wanna explain it in brief with the help of we use to scenario

@elmonkeylp why not delete the whole file that is bringing in issues instead of commenting its sections? — Gathide, Apr 18 '20 at 18:54

django 1.7 migrate gets error "table already exists"

3 Answers3

Linked

Related