Ok, it is clear now.
SQLite unfortunatelly does not support "ALTER TABLE ADD CONSTRAINT"
command.
So the "REFERENCES" clause is not possible if the referenced table is
missing, there is no alter, and of course django will not re-arrange
my definition order.
The same applies to many-to-many relations.
At least it creates an index on the foreign key column, so query will
be faster just the constraint is missing.
I think django does the maximum it can with sqlite :)
Since I am just learning django I can live without constraints and
later I will use some "more complete" db, no frustration anymore :)
Thanks again for the informations, I hope it was usefull not just for
me.
Best regards,
Gergely
On márc. 7, 13:43, Gergely <gergely...@gmail.com> wrote:
> Thanks a lot Tom!
>
> Now I see that not the "REFERENCES" is missing but the "ALTER" at the
> end of the script.
> And of course the reason is clear, you are right.
>
> I will test it with the latest django and sqlite and report the result
> here.
>
> Regards,
> Gergely
>
> On márc. 7, 13:33, Tom Evans <tevans...@googlemail.com> wrote:
>
>
>
>
>
>
>
> > 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.
