Django Signals

• Django는 시그널 포착기를 포함한다.

• Signal dispatcher : 분리된 애플리케이션들이 프레임워크상 어디서든 액션이 발생하면 통지받게끔 함

 

signal은 sender들에게 하여금 어떤 액션이 발생했다는 것을 receiver들에게 전달하는 것을 가능하게 해준다.

*주의!

Signal은 느슨한 결합을 제공하지만, 디버깅, 수정이 어려운 코드로 만들어 질 수 있다.

가능하면 신호를 통해 발송하는 것보다는 직접 핸들링 코드를 호출하는 방법을 선택해야 한다.

 

Signal을 받기 위해, receiver는 signal.connect() 메서드를 사용한 리시버 함수를 등록해야 한다.

리시버 함수는 signal을 받았을 때 호출된다. 모든 signal의 리시버 함수들은 등록 순서대로 한번에 한번 호출된다.

 

모든 signal은 키워드 인자를 보낸다, 그리고 그 키워드 인자들을 언제든 바꾼다.

Request_fifnished의 경우, 어떤 인자도 보내지 않는 것으로 문서화되어 있다.

 

Receiver(signal, **kwargs)

• User가 save되어서 created 될 때마다 user가 sender로서 receiver에게 instance와 어떤 signal인지 그 종류를 담아서 보낸다
• User가 생성됨에 따라 profile을 자동으로 만들게 할 수 있다.

• Receiver : 신호에 연결될 콜백 함수
• Sender : 신호를 수신할 특정 발신자 지정
• Weak : 기본적으로 신호 처리기를 약한 참조로 저장

함수를 만들고 -> 파라미터값을 정해진 대로 세팅 -> 시그널 종류의 함수에 connect 함수를 활용하여, 우리가 정의한 함수와 모델을 이어준다.

 

특징

1. Pre/Post init

• 특정 model이 init 될 때, 생성자가 호출이 된다.
• q = Question(question_text="What's new?", pub_date=timezone.now()) 
• Kwargs : 특정 모델의 att 값이 전달되는 것

 

    2. Pre/Post save

• Sender는 모델 클래스, 인스턴스는 실제 당사자 모델 인스턴스, raw는 True로 DB에서 다른 레코드에 대한 쿼리를 날리거나 수정을 하지 못하게 한다

 

단점

1. Threading이나, 비동기 작업이 아니다

• 단순하게 callback 형태로, 실행할 백그라운드 스레드나 작업자가 없다.

    2. 코드의 유지관리가 어렵다

• 쓸모 없는 파일 분산 가능성
• 특정 모델에 대해 models 정의에 signal 함수가 정의되어 있는 것도 아니고, 해당 model이 시그널이 등록되어 있는지 아닌지도 찾기 힘들 수 있다
• Transaction 문제: save 된 뒤에 callback으로 처리하는 구조기 때문에, 해당 함수에서 sender와 dependency가 있는 특정 모델을 생성할 경우 rollback이 어려움
• 코드가 분산되므로 가독성 저하