Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Django Migration Is Failing

I have a django/postgresql application. Whenever I run my latest migration, I receive the following error:

ValueError: Found wrong number (0) of constraints for package(speciality, title)

I believe I need to customize the migration, but what change I should make.

This is the migration:

operations = [

    migrations.AddField(

        model_name='package',

        name='speciality',

        field=models.ManyToManyField(related_name='specialities', to='speciality.Speciality', blank=True),

    ),

    migrations.AlterField(

        model_name='package',

        name='title',

        field=models.CharField(unique=True, max_length=50),

    ),

    migrations.AlterUniqueTogether(

        name='package',

        unique_together=set([]),

    ),

    migrations.RemoveField(

        model_name='package',

        name='speciality',

    ),

]

This is my current table configuaration for this model:

sleepyfish=# \d package Table "public.package" Column | Type | Modifiers
---------------+--------------------------+------------------------------------------------------ id | integer | not null default nextval('package_id_seq'::regclass) created_at | timestamp with time zone | not null updated_at | timestamp with time zone | not null title | character varying(50) | not null description | text | status | boolean
| not null price | numeric(8,2) | not null speciality_id | integer | Indexes: "package_pkey" PRIMARY KEY, btree (id) "package_speciality_id_3aeb5c97679442e4_uniq" UNIQUE CONSTRAINT, btree (speciality_id, title) "package_66db61fe" btree (speciality_id) Foreign-key constraints: "package_speciality_id_4255b58fe1ae00c0_fk_speciality_id" FOREIGN KEY (speciality_id) REFERENCES speciality(id) DEFERRABLE INITIALLY DEFERRED Referenced by: TABLE "claimedpackage" CONSTRAINT "claimedpackage_package_id_9e1da358fbb9a46_fk_package_id" FOREIGN KEY (package_id) REFERENCES package(id) DEFERRABLE INITIALLY DEFERRED TABLE "package_service" CONSTRAINT "package_service_package_id_3b0ea08bfcd8da76_fk_package_id" FOREIGN KEY (package_id) REFERENCES package(id) DEFERRABLE INITIALLY DEFERRED

like image 801
Bryant James Avatar asked Sep 08 '17 15:09

Bryant James


3 Answers

This is an alternative if answer from arjun27 no solving your problem.

Today I got same problem (exact keyword with the question) when I tried to remove unique_together from Django Model. I'm using Django 1.11.

Read documentation and reference from arjun27, as I understand, the migration process will try to find UNIQUE CONTRAINST on Postgresql for field (speciality, title), using above case.

I try to find the UNIQUE CONSTRAINT on table but not found.

so, I create the UNIQUE CONSTRAINT directly from SQL console.

ALTER TABLE package ADD UNIQUE (speciality, title)

then I re-run the migration.

hope it helps.

like image 126
oon arfiandwi Avatar answered Nov 19 '22 06:11

oon arfiandwi


It looks like you are running into this documented Django bug. The bug was triaged as invalid (and rightly so), so unfortunately there is no clean solution to the problem.

The unique together constraint in the database definition is shown as

"package_speciality_id_3aeb5c97679442e4_uniq" UNIQUE CONSTRAINT,
btree (speciality_id, title)

If you want to remove this constraint, you will need to ensure the unique_together definition in the migration file is consistent with the database definition. Try replacing the AlterUniqueTogether line with this:

migrations.AlterUniqueTogether(
    name='package',
    unique_together=set([('speciality_id', 'title')]),
),
like image 21
arjunattam Avatar answered Nov 19 '22 07:11

arjunattam


Just in case anyone runs into the same issue as I did:
I have a multi-tenant system wherein each tenant has its own schema, with the public schema left empty.

When Django tries to inspect the current state of the database to delete the real unique constraint matching the historical one, it only looks inside the public schema, ignoring the schema information set in OPTIONS from the DATABASES setting.

There are a couple of tickets open regarding this issue, with no real resolution in sight: #6148 and #22673.

You can always write your own database backend to circumvent the issue, or submit a pull-request to Django!

like image 2
Raphaël Gomès Avatar answered Nov 19 '22 06:11

Raphaël Gomès