DB foreign key constraints : Django 1.7 regression ?

[not...@gmail.com]

Hi !

Just tested the following:

• create clean DB
• run syncdb
• compare obtained tables when using Django 1.6.8 and Django 1.7.1

My findings :

In Django 1.7, some fields with models.ForeignKey no longer get the DB constraint.

In Django 1.6, I indeed get (in postgresql) for instance:

CONSTRAINT TABLE_FIELD_id_fkey FOREIGN KEY (FIELD_id)

          REFERENCES django_content_type (id) MATCH SIMPLE

          ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,

The models for which it fails are always:

• ContentType
  
• Auth.Group
  
• Auth.permission
  
• django_site

My local apps are always defined after "django.contrib.contenttypes" and "django.contrib.auth" in INSTALLED_APPS.

Putting "django.contrib.contenttypes" as my last app does not change the DB construction.

So does it have to do with the order in INSTALLED_APPS ?

Is it a regression ?

Thanks for the input !

NotSqrt

[Carl Meyer]

Hi NotSqrt,

On 10/29/2014 11:53 AM, not...@gmail.com wrote:
> Just tested the following:
>
> * create clean DB
> * run syncdb
> * compare obtained tables when using Django 1.6.8 and Django 1.7.1

>
> My findings :
>
> In Django 1.7, some fields with models.ForeignKey no longer get the DB
> constraint.
>
> In Django 1.6, I indeed get (in postgresql) for instance:
> CONSTRAINT TABLE_FIELD_id_fkey FOREIGN KEY (FIELD_id)
> REFERENCES django_content_type (id) MATCH SIMPLE
> ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY
> DEFERRED,
>
> The models for which it fails are always:
>

> * ContentType
> * Auth.Group
> * Auth.permission
> * django_site

>
> My local apps are always defined after "django.contrib.contenttypes" and
> "django.contrib.auth" in INSTALLED_APPS.
> Putting "django.contrib.contenttypes" as my last app does not change the
> DB construction.
>
> So does it have to do with the order in INSTALLED_APPS ?
> Is it a regression ?

I don't have time to look into this and try to reproduce at the moment,
but if the situation is as you've described it (and it's not due to
something else specific to your project), it is certainly a regression
and a bug. If you can reproduce with a fixed set of steps (starting from
a fresh "startproject" for each Django version), please do file a bug at
code.djangoproject.com with those reproduction instructions. Thanks!

Carl

[not...@gmail.com]

Hi !

I have identified very reproducible steps (cf attached file).

It fails with a single app with a single model with single field which is a foreign key to ContentType.

Testable instantly with tox :

• install django and tox in your prefered env
• run steps.sh wichi will create all files.
• configure the settings (postgresql, db name, password, ..), add the "example" app to the INSTALLED_APPS
• run tox from the "fkregression" folder

I coded a test that checks for the actual foreign keys in the system table of PostgreSQL, looking for multiple foreign keys.

It passes on django 1.5 and 1.6, but fails with django 1.7

I will fill a bug with similar info.

NotSqrt

[Daniel Roseman]

Have you tried putting contenttypes and auth as dependencies in your migration?

--

DR. 

[not...@gmail.com]

Thanks Daniel, that was it (instead of removing the migrations folder, I now use makemigrations).

I expected everything to work without the need of migrations.

So I guess that with django 1.7, it is simply mandatory to use migrations.

It is indeed stated in https://docs.djangoproject.com/en/1.7/topics/migrations/#unmigrated-dependencies

I guess adding a nice big system check would have helped me !

Is that addition worthy of a ticket ?

Thanks

NotSqrt

[Carl Meyer]

On 10/30/2014 06:09 AM, not...@gmail.com wrote:
> Thanks Daniel, that was it (instead of removing the migrations folder, I
> now use makemigrations).
>
> I expected everything to work without the need of migrations.
> So I guess that with django 1.7, it is simply mandatory to use migrations.
>
> It is indeed stated
> in https://docs.djangoproject.com/en/1.7/topics/migrations/#unmigrated-dependencies
>
> I guess adding a nice big system check would have helped me !
> Is that addition worthy of a ticket ?

I'm not sure off the top of my head how feasible such a check would be,
but in principle I think it would be a good idea - so yes, I'd recommend
opening a ticket.

Carl

[not...@gmail.com]

Ticket created at https://code.djangoproject.com/ticket/23741 , with a basic implementation (that detected missing relations on non-managed models on my project !!).

Thanks for the help !