Django уникальна для postgres: применяется ORM или DB? - PullRequest
4 голосов
/ 11 июля 2011

Когда я смотрю на sqlall для файла models.py, который содержит операторы unique_together, я не замечаю ничего похожего на принудительное исполнение.

В моем представлении я могу представить, что эти знания могут помочь базе данныхоптимизировать запрос следующим образом:

"Я уже нашел строку со спамом 42 и яйцами 91, поэтому при поиске яиц 91 мне больше не нужно проверять строки со спамом 42."

Прав ли я, что эти знания могут быть полезны для БД?

Прав ли я, что они не применяются таким образом (т. Е. Применяются только ORM)?

Если да для обоих, это недостаток?

1 Ответ

4 голосов
/ 26 июля 2011

Вот пример, как это должно выглядеть.Предположим, что у вас есть модель:

class UserConnectionRequest(models.Model):
    sender = models.ForeignKey(UserProfile, related_name='sent_requests')
    recipient = models.ForeignKey(UserProfile, related_name='received_requests')
    connection_type = models.PositiveIntegerField(verbose_name=_(u'Connection type'), \
                                                  choices=UserConnectionType.choices())

    class Meta:
        unique_together = (("sender", "recipient", "connection_type"),)

Запуск sqlall возвращает:

CREATE TABLE "users_userconnectionrequest" (
    "id" serial NOT NULL PRIMARY KEY,
    "sender_id" integer NOT NULL REFERENCES "users_userprofile" ("id") DEFERRABLE INITIALLY DEFERRED,
    "recipient_id" integer NOT NULL REFERENCES "users_userprofile" ("id") DEFERRABLE INITIALLY DEFERRED,
    "connection_type" integer,
    UNIQUE ("sender_id", "recipient_id", "connection_type")
)

Когда эта модель правильно синхронизирована с БД, она имеет уникальное ограничение (postgres):

CONSTRAINT users_userconnectionrequest_sender_id_2eec26867fa22bfa_uniq UNIQUE (идентификатор отправителя, идентификатор получателя, тип подключения),

...