Code

Opened 7 years ago

Closed 7 years ago

#4930 closed (duplicate)

foreign key constraint not set in database for FKs to another application's models

Reported by: James <james_027@…> Owned by: PhiR
Component: Database layer (models, ORM) Version: master
Severity: Keywords: foreign key backend
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I am very new to django, I am creating a model with a field of models.ForeignKey(User) #django.contrib.auth.models import User. When I look at the database my table has no foreign key define. Another example is the django.contrib.admin.models.LogEntry model it has user = models.ForeignKey(User) which is also from django.contrib.auth.models.user.

When the relationship is within the same namespace (am I using the right term, pls correct me) the manage.py syncdb create the tables without a problem if all the tables are create on the same time, but if the tables weren't created the same time it also fail to create the foreign keys.

Is this a bug of django or a shortcomings of database driver?

Thanks
james

Attachments (0)

Change History (9)

comment:1 Changed 7 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

You're going to need to provide an example to prove this doesn't work. Table creation has been used successfully by _many_ people without difficulty.

comment:2 Changed 7 years ago by James <james_027@…>

  • Resolution worksforme deleted
  • Status changed from closed to reopened

a simple sample is the django.contrib.admin.models.LogEntry from the django.contrib.admin application. where in the django_admin_log table has no foreign key define.

comment:3 Changed 7 years ago by Brian Rosner <brosner@…>

  • Resolution set to invalid
  • Status changed from reopened to closed

You are not providing enough context and details to prove what you are saying is true. Please move your questions about Django to the django-users mailing list. If you are performing a syncdb after creating a new field in your model then it won't be created since syncdb will only create tables if they don't already exist in your database.

comment:4 Changed 7 years ago by james <james_027@…>

  • Resolution invalid deleted
  • Status changed from closed to reopened

here is my model,

from django.db import models
from django.contrib.auth.models import User

# Create your models here.
DEPARTMENTS = (

('HRD', 'HRD'),
('ACT', 'Accounting'),
('PUR', 'Purchasing'),
('LOG', 'Logistics'),
('PRO', 'Production'),
('MKG', 'Marketing'),
('EXP', 'Export'),
('ITD', 'IT'),

)

LEVELS = (

('SM', 'Senior Manager'),
('MR', 'Manager'),
('SP', 'Supervisor'),
('ST', 'Staff'),

)

class Profile(models.Model):

"""KSK Employee accounts to use this application"""

user = models.ForeignKey(User)
department = models.CharField(maxlength=3, choices=DEPARTMENTS)
level = models.CharField(maxlength=3, choices=LEVELS)

comment:5 Changed 7 years ago by SmileyChris

  • Resolution set to invalid
  • Status changed from reopened to closed

James, as Brian has already said, take this to the django-users mailing group (or IRC at least). Until you have thrashed it out there, leave this ticket closed.

comment:6 Changed 7 years ago by PhiR

  • Keywords backend added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Summary changed from foreign key on database not created with models referencing from other application to foreign key constraint not set in database for FKs to another application's models
  • Triage Stage changed from Unreviewed to Design decision needed
  • Version changed from 0.96 to SVN

i think he refers to the same issue as #5113. Basically it seems foreign key are not always marked as such in the DB but are sometimes (how often remains to be seen) created as plain integer fields with no constraints.

comment:7 Changed 7 years ago by PhiR

  • Owner changed from adrian to PhiR
  • Status changed from reopened to new

#5113 is closed in favor of #4193, which exhibits the same random pattern.

mysite/polls/models.py;

from django.db import models
from mysite.timesheet.models import *

class Choice(models.Model):
    choice = models.CharField(maxlength=200)
    votes = models.IntegerField()
    client = models.ForeignKey(Client)

mysite/timesheet/models.py;

from django.db import models

class Client(models.Model):
    name = models.CharField(maxlength=200)
    shortname = models.CharField('short name', maxlength=5)
    datecreated = models.DateTimeField('date created')
$ ./manage.py sql polls
BEGIN;
CREATE TABLE "polls_choice" (
    "id" integer NOT NULL PRIMARY KEY,
    "choice" varchar(200) NOT NULL,
    "votes" integer NOT NULL,
    "client_id" integer NOT NULL
)
;
COMMIT;

Doing the FK from Client to Choice returning the right SQL. Again it sounds like an ordering bug.

comment:8 Changed 7 years ago by PhiR

might be relevant:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.admin',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'mysite.polls',
    'mysite.timesheet'
)

comment:9 Changed 7 years ago by ubernostrum

  • Resolution set to duplicate
  • Status changed from new to closed

Closing as dupe of #4193.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.