views:

43

answers:

1

When using syncdb the following schema is created:

CREATE TABLE "MyApp_supervisor" (
    "id" integer NOT NULL PRIMARY KEY,
    "supervisor_id" integer NOT NULL REFERENCES "MyApp_employee" ("id"),
    "section_id" integer NOT NULL REFERENCES "MyApp_section" ("id")
);

When using migrate, it is changed to:

CREATE TABLE "MyApp_supervisor" (
    "id" integer NOT NULL PRIMARY KEY,
    "supervisor_id" integer NOT NULL,
    "section_id" integer NOT NULL
);

Why does South do that? I haven't noticed a functional problem yet, but I'm weary of ignoring this...

Can someone shed some light on what is happening here?

A: 

It's probably because foreign key support was introduced in SQLite only in version 3.6.19, as this page says:

This document describes the support for SQL foreign key constraints introduced in SQLite version 3.6.19.

It looks like version 3.6.19 was tagged on 14th Oct 2009, which is actually quite recent so it's probably not deployed everywhere yet.

I guess the choice was made not to declare foreign keys because they're not widely supported yet, depending on the version of SQLite used. (This being said, the foreign key syntax was supported before, but simply ignored.)

Bruno
Not likely: SQLite has supported the REFERENCES *syntax* for a very long time; it's only enforcing it that was introduced recently. There's no harm in specifying foreign keys with older versions.
Glenn Maynard
Yes, that's what I said. I think the developers might have considered using REFERENCES at all to be superfluous anyway (or giving the false impression they'd be there).
Bruno