On Mon, Mar 7, 2011 at 12:04 PM, Tom Evans <tevans...@googlemail.com> wrote:
> If so, then there is no difference in the SQL generated - why would there be?
>
> Cheers
>
> Tom
>
Oh, I'm waay wrong:
class Series(models.Model):
pass
class Episode(models.Model):
series = models.ForeignKey('Series')
=>
BEGIN;
CREATE TABLE "app_series" (
"id" serial NOT NULL PRIMARY KEY
)
;
CREATE TABLE "app_episode" (
"id" serial NOT NULL PRIMARY KEY,
"series_id" integer NOT NULL REFERENCES "app_series" ("id")
DEFERRABLE INITIALLY DEFERRED
)
;
CREATE INDEX "app_episode_series_id" ON "app_episode" ("series_id");
COMMIT;
where as:
class Episode(models.Model):
series = models.ForeignKey('Series')
class Series(models.Model):
pass
=>
BEGIN;
CREATE TABLE "app_episode" (
"id" serial NOT NULL PRIMARY KEY,
"series_id" integer NOT NULL
)
;
CREATE TABLE "app_series" (
"id" serial NOT NULL PRIMARY KEY
)
;
ALTER TABLE "app_episode" ADD CONSTRAINT "series_id_refs_id_61c5b6e4"
FOREIGN KEY ("series_id") REFERENCES "app_series" ("id") DEFERRABLE
INITIALLY DEFERRED;
CREATE INDEX "app_episode_series_id" ON "app_episode" ("series_id");
COMMIT;
Django 1.2.5, using postgres_psycopg2 backend.
I can understand why it does this. The table it references needs to
exist before Django can create a reference to it. By declaring it in
one order leads Django to assume that the table does not exist yet,
and to defer the creation of the reference constraint pointing to it.
To have both situations producing the same SQL would require Django to
understand and re-order the table creation queries, and that isn't
necessary or worthwhile - the order that the developer chose is used
instead.
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
