#2260 closed defect (fixed)
[patch] Model tables get created in the wrong order
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | normal | Keywords: | |
Cc: | mir@… | Triage Stage: | Unreviewed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django's sqlreset sometimes generates CREATE statements in the wrong order.
My models.py file:
from django.db import models class AuctionElement(models.Model): name = models.CharField(maxlength=500) class AuctionDetails(models.Model): element = models.ForeignKey(AuctionElement) name = models.CharField(maxlength=500)
At least on my machine Django tries to create a table for AuctionDetails before AuctionElement. It might be difficult to reproduce since the result depends on model names: change them a bit and you will get different order.
As far as I can tell Django neither keeps track of model sequence nor tries to order them by dependencies. The order as defined in models.py is lost in db.models.loading.register_models.
Attachments (1)
Change History (8)
comment:1 by , 18 years ago
Cc: | added |
---|
comment:2 by , 18 years ago
I checked right now in rev 3236. The SQL created specifies foreign key references inside CREATE TABLE statements.
comment:3 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This appears to be fixed.
Using rev 3519, postgres, and the models in the ticket description, manage.py sql scratch yields:
BEGIN; CREATE TABLE "scratch_auctiondetails" ( "id" serial NOT NULL PRIMARY KEY, "element_id" integer NOT NULL, "name" varchar(500) NOT NULL ); CREATE TABLE "scratch_auctionelement" ( "id" serial NOT NULL PRIMARY KEY, "name" varchar(500) NOT NULL ); ALTER TABLE "scratch_auctiondetails" ADD CONSTRAINT element_id_refs_id_75764088 FOREIGN KEY ("element_id") REFERENCES "scratch_auctionelement" ("id"); COMMIT;
If it's still an issue, which database are you using?
comment:4 by , 18 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Version: | → SVN |
The problem apprears when you call sql or sqlreset on a database that
already contains those tables. This is usually the case with
sqlreset.
Django declares foreign keys outside of CREATE TABLE only if the other
table does not exist in the database yet. If you call sql or sqlreset
with an already populated database then it is very likely that the
table does exist at the moment Django checks for it.
by , 18 years ago
Attachment: | fix_tables_created_in_wrong_order.diff added |
---|
comment:5 by , 18 years ago
Summary: | Model tables get created in the wrong order → [patch] Model tables get created in the wrong order |
---|
The attached patch changes get_sql_create to assume that all models
belonging to the application being installed are not present or will
be dropped form the database before executing CREATE statements.
comment:6 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:7 by , 17 years ago
seduction Here's my post on how to get laid in the next month or two. This post does not maximize your chances of "getting really good at pickup" - in fact, it does the opposite.
Which version did you use? There has been a lot of changes in the last few days, and I think this is all fixed by issueing the foreign key constraints after both involved tables have been created.