2017-07-04 10 views
0

ユーザーが製品を作成する場合、super(Product,self).save(*args,**kwargs)を呼び出す前に、複数のアクションをsave()メソッドで実行する必要があります。複数の特定のシグナルではなく、1つの一般的なシグナルを好むべきですか?

pre_save信号を1つだけ使用してこれらのすべての動作を実行する必要があるかどうか、またはこれらの動作ごとに個別に信号を作成する方が良いかどうかはわかりません。

簡単な例は、(私は信号によってsaveオーバーライドを交換するつもりです):

class Product(..): 
    def save(...): 
     if not self.pk: 
      if not self.category: 
       self.category = Category.get_default() 
      if not self.brand: 
       self.brand = 'NA' 
     super(Product,self).save(*args,**kwargs) 
     ... 

SO

@receiver(pre_save,sender=Product) 
def set_attrs(instance,**kwargs): 
    if kwargs['created']: 
     instance.category = Category.get_default() 
     instance.brand = 'NA' 

OR

@receiver(pre_save,sender=Product) 
def set_category(instance,**kwargs): 
    if kwargs['created']: 
     instance.category = Category.get_default() 

@receiver(pre_save,sender=Product) 
def set_brand(instance,**kwargs): 
    if kwargs['created']: 
     instance.brand = 'NA' 

この単純な例です。この場合、一般的なset_attrsは、おそらく十分なはずですが、userためuserprofileを作成するなどの異なるアクションを持つ、より複雑な状況があり、その後、userplanなど

このためのいくつかのベストプラクティスのアドバイスはありますか?あなたの意見ですか? 1つのモデルのインスタンス上のアクションが別のモデルに影響を与える場合は、単に事実を出し

+0

私は保守のために、それらを分割する方が良いだろうと言うでしょう。しかし、私は一般的にシグナルを使用しないようにし、マネージャメソッドなどを使用します。 –

答えて

0

、それは、助言の単一部品として

を指摘することができ、信号が約行くためのクリーンな方法です。これは、信号と一緒に行くことができる例です。 save()メソッドの呼び出しをanother_modelのように避けることができます。

例を詳しく説明すると、save()メソッドをオーバーライドするとき、一般的な作業はモデルのいくつかのフィールドからスラッグを作成することです。複数のモデルでこのプロセスを実装する必要がある場合は、pre_saveシグナルを使用すると、各モデルのsave()メソッドでハードコーディングするのではなく、利点があります。

また、バルク操作では、これらの信号とメソッドは必ずしも呼び出される必要はありません。ドキュメントから

は、

オーバーライドモデル法は、クエリセットを使用して、バルク内のオブジェクトを削除する場合、またはオブジェクトの削除()メソッドが必ずしも呼び出されないこと

注一括操作で呼び出されていませんカスケード削除の結果として。カスタマイズされた削除ロジックが確実に実行されるようにするには、pre_deleteおよび/またはpost_deleteシグナルを使用できます。

残念ながら、save()、pre_save、およびpost_saveのいずれも呼び出されないため、オブジェクトをバルクで作成または更新する際の回避策はありません。複数の基準については

関連する問題