django-сигналы против триггеров?

Я читал о сигналах django (http://docs.djangoproject.com/en/dev/topics/signals/), но, насколько я понимаю, сигналы никогда не преобразуются в буквальные триггеры SQL (http://en.wikipedia.org/wiki/Database_trigger).

если я прав, что сигналы и триггеры разные, то какой из них лучше и каким образом? Какая лучшая практика?

....................

вот конкретный пример, если вы хотите один:

class Location(models.Model):
    name = models.CharField(max_length=30)

class Person(models.Model):
    location = models.ForeignKey('Location')

class Team(models.Model):
    locations = models.ManyToManyField('Location')

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

11
django django-signals sql triggers

3 ответов

ни. Лучший инструмент для этой работы -модель проверки - вы можете написать свое пользовательское правило проверки там, и оно будет применяться в администраторе и ваших собственных приложениях.

16

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

вот пример, как это работает:

class Example(models.Model):
    ''' Example of Model (I hate foo-bars!) '''
    age = models.IntegerField()
    can_buy_beer = models.BooleanField(default=False)


def set_can_buy_beer(sender, instance, **kwargs):
    ''' Trigger body '''
    if instance.age >= 21:
        instance.can_buy_beer = True
    else:
        instance.can_buy_beer = False

# ↓ Magic — now, field Example.can_buy_beer will be autocalculated on each save!
pre_save.connect(set_can_buy_beer, sender=Example)
7

вы можете использовать триггеры для реализации такого рода ограничений, но я бы не стал полагаться на это. Это может быть сделано только как вторичное принуждение, в то время как первичное должно быть проверкой модели, как уже сказал Даниэль.

Что касается DB триггеры vs Django сигналы они более разные общие. Единственное, что их объединяет, это то, что оба вызываются при изменении сущности. Но сущности отличаются очень сильно много.

триггеры монитор изменения строки базы данных, таким образом, они работают на необработанных табличных данных. Код триггера запускается СУБД.

В отличие от триггеров сигналы мониторинг изменений объектов домена. В общем случае модель Django состоит из данных из нескольких строк таблицы (рассмотрим наследование модели и связанные подмножества объектов). Код сигнала запускается Django.

2