Внешнему ключу нужно значение из таблицы ключей, чтобы соответствовать столбцу в другой таблице

Question

Прошу прощения за чрезмерное количество кода, но я не уверен, смогу ли я объяснить свой вопрос иначе

У меня есть проект Django, над которым я работаю, который имеет следующее:

class Project(models.Model):
    name = models.CharField(max_length=100, unique=True)
    dir  = models.CharField(max_length=300, blank=True, unique=True )

    def __unicode__(self):
        return self.name;

class ASClass(models.Model):
    name      = models.CharField(max_length=100)
    project   = models.ForeignKey(Project, default=1)

    def __unicode__(self):
        return self.name;

class Entry(models.Model):
    project     = models.ForeignKey(Project, default=1)
    asclasses   = models.ManyToManyField(ASClass)

Вот вопрос:

Есть ли способ, не переопределяя функцию сохранения модели, сделать так, чтобы записи допускали только классы с одинаковым идентификатором проекта?

*********************************************** ************ Начать редактировать ************************************ **********************
Чтобы было ясно, я не против переопределения сохранения. Я фактически уже переопределил это в этом случае, чтобы обеспечить собственность, не перечисленную выше. Я уже знаю, как ответить на этот вопрос, просто расширив это переопределение, поэтому просто сказать: «Вы можете переопределить сохранение» не поможет.

Мне интересно, нет ли лучшего способа сделать это, есть ли собственная реализация Django и если тип ключа уже существует.

*********************************************** ************ End Edit ************************************ ***********************

Есть ли способ сделать это и в Postgresql?

(для примера, вот код для создания таблиц в Postgresql) Это создало следующие таблицы:

CREATE TABLE blog_asclass
(
  id serial NOT NULL,
  "name" character varying(100) NOT NULL,
  project_id integer NOT NULL,
  CONSTRAINT blog_asclass_pkey PRIMARY KEY (id),
  CONSTRAINT blog_asclass_project_id_fkey FOREIGN KEY (project_id)
      REFERENCES blog_project (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED
)

CREATE TABLE blog_entry
(
  id serial NOT NULL,
  project_id integer NOT NULL,
  build_date timestamp with time zone NOT NULL,
  CONSTRAINT blog_entry_pkey PRIMARY KEY (id),
  CONSTRAINT blog_entry_project_id_fkey FOREIGN KEY (project_id)
      REFERENCES blog_project (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED
)

CREATE TABLE blog_entry_asclasses
(
  id serial NOT NULL,
  entry_id integer NOT NULL,
  asclass_id integer NOT NULL,
  CONSTRAINT blog_entry_asclasses_pkey PRIMARY KEY (id),
  CONSTRAINT blog_entry_asclasses_asclass_id_fkey FOREIGN KEY (asclass_id)
      REFERENCES blog_asclass (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,
  CONSTRAINT blog_entry_asclasses_entry_id_fkey FOREIGN KEY (entry_id)
      REFERENCES blog_entry (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,
  CONSTRAINT blog_entry_asclasses_entry_id_key UNIQUE (entry_id, asclass_id)
)

CREATE TABLE blog_project
(
  id serial NOT NULL,
  "name" character varying(100) NOT NULL,
  dir character varying(300) NOT NULL,
  CONSTRAINT blog_project_pkey PRIMARY KEY (id),
  CONSTRAINT blog_project_dir_key UNIQUE (dir),
  CONSTRAINT blog_project_name_key UNIQUE (name)
)

Answer 1

Вы можете использовать сигнал pre_save и вызвать ошибку, если они не совпадают ... Эффект будет аналогичен переопределению сохранения (вызывается перед сохранением)

Проблема при создании / удалении / обновлении отношения «многие ко многим» не приведет к сохранению (или, следовательно, pre_save или post_save)

Обновление

Попробуйте использовать аргумент through в отношении многих ко многим

Это позволяет вам вручную определить промежуточную таблицу для отношения m2m, которая даст вам доступ к сигналам, а также к функциям.

Тогда вы можете выбирать сигналы или перегрузки, как вам нравится.

Answer 2

Я уверен, что вы могли бы сделать это на уровне PostgreSQL с помощью триггера , который вы можете добавить в исходный SQL-файл Django , чтобы он автоматически создавался в syncdb.

На уровне модели Django, чтобы получить полезный ответ, вам необходимо выяснить, почему вы против переопределения метода save (), поскольку в настоящее время это правильный (и, возможно, единственный) способ обеспечить это вид проверки.

Django 1.2 будет (надеюсь) включать полную платформу проверки модели .