#24447: Migrations do not add a FK constraint for an existing column
----------------------------+------------------------------------
     Reporter:  ganwell     |                    Owner:  nobody
         Type:  Bug         |                   Status:  new
    Component:  Migrations  |                  Version:  1.7
     Severity:  Normal      |               Resolution:
     Keywords:              |             Triage Stage:  Accepted
    Has patch:  1           |      Needs documentation:  1
  Needs tests:  0           |  Patch needs improvement:  1
Easy pickings:  0           |                    UI/UX:  0
----------------------------+------------------------------------

Old description:

> Migrations failed when introducing foreign keys on existing fields.
>
> Pull request: https://github.com/django/django/pull/4235
> Branch with fix:
> https://github.com/ganwell/django/tree/master_missing_create_fk_sql
> Branch with unittest but no fix:
> https://github.com/ganwell/django/tree/master_missing_create_fk_sql_fail
>
> Consider following model:
>
> {{{
> class ForeignKeyTest(models.Model):
>     id = models.AutoField(primary_key=True)
>     customer = models.IntegerField()
>
> class Customer(models.Model):
>     id = models.AutoField(primary_key=True)
> }}}
>
> Then it gets migrated to this:
>
> {{{
> class ForeignKeyTest(models.Model):
>     id = models.AutoField(primary_key=True)
>     customer = models.ForeignKey('Customer')
>
> class Customer(models.Model):
>     id = models.AutoField(primary_key=True)
> }}}
>
> The second migration won't create the foreign key. This does not fail
> with sqlite! Because these migrations are handled differently. It will
> fail with MySQL and probably Postgres too. I wrote a unittest and tested
> it with MySQL: master_missing_create_fk_sql_fail fails and
> master_missing_create_fk_sql is ok.
>
> The code didn't detect this case - if old_field.rel doesn't exist
> alter_field() must always create the foreign key and ONLY if .rel exists
> it must check .db_constraint, too. Since no .rel also means there was no
> foreign key before.
>
> I will of course redo the pull request to get clean history. I also fixed
> this in 1.7.

New description:

 Pull request: https://github.com/django/django/pull/4235

 Consider following model:

 {{{
 class ForeignKeyTest(models.Model):
     id = models.AutoField(primary_key=True)
     customer = models.IntegerField()

 class Customer(models.Model):
     id = models.AutoField(primary_key=True)
 }}}

 Then it gets migrated to this:

 {{{
 class ForeignKeyTest(models.Model):
     id = models.AutoField(primary_key=True)
     customer = models.ForeignKey('Customer')

 class Customer(models.Model):
     id = models.AutoField(primary_key=True)
 }}}

 The second migration won't create the foreign key. This does not fail with
 sqlite! Because these migrations are handled differently. It will fail
 with MySQL and probably Postgres too.

 The code didn't detect this case: if old_field.rel doesn't exist
 alter_field() must always create the foreign key and ONLY if .rel exists
 it must check .db_constraint, too. Since no .rel also means there was no
 foreign key before.

--

Comment (by ganwell):

 Removed redundant information and chose clearer title.

--
Ticket URL: <https://code.djangoproject.com/ticket/24447#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e689d3acea7378c89551ed9d9daa5f80%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to