안녕하세요. 이번 시간에는 field 단위로 동작하는 validator에 대해 알아보겠습니다.

 


 먼저 아래 프로그램을 보겠습니다.

 

  x: int = Field(gt=5)라고 되어 있습니다. pydantic의 Field인데요. gt는 greater than의 약자입니다. 즉, 5보다 커야 된다는 조건이 있어야 합니다. 9번째 줄에는 custom validator를 작성하였는데요. "x"는 필드명을 의미합니다. 필드명 x에 대한 커스텀 벨리데이터 함수는 check_x를 의미해요.

 

 1번째 인자는 cls, 2번째 인자는 v인데요. v는 실제로 check_x에 들어온 필드 x의 값을 의미합니다. 보통 이 v값을 검증해서, 조건에 맞지 않으면 ValueError를 떨어트리게 됩니다. pre=True라고 되어 있는데요. 어떻게 실행되는지 보겠습니다.

 

 

 x에 -6을, y에 0을 넘겨주었습니다. 그러면, pre=True이므로 check_x가 실행됩니다. 들어온 v의 값이 10보다는 작았으므로, -v 값인 6이 리턴됩니다. 그 다음에 Field(ge=5) Validator로 넘어가는데요. 6은 5보다 크므로 참이 리턴됩니다.

 

 

 post /res가 호출되면, 그대로 res_request.x와 res_request.y를 돌려주게 되는데요. validation을 하는 과정에서, res_request.x의 값에 -1이 곱해집니다.

 

 결과는 x가 6, y가 0이 나오게 됩니다.

 

 반대로 이 경우에는 어떨까요? Field(gt=5) 먼저 수행되게 됩니다.

 

 다시 post /res에 요청을 요래 날려보겠습니다.

 

 그러면 아까와 다르게 not_gt 에러가 뜨면서 422가 떨어짐을 알 수 있어요. int는 gt, ge, lt, le 등을 상당히 많이 쓰니 알아두면 좋습니다.

 

 


 문자열의 경우도 검증을 많이 합니다. 이 중에서 제가 자주 쓰는 regex만 알아보겠습니다. regex는 패턴에 맞지 않으면 실패하게 됩니다. 예를 들어, ResRequest schema의 x는 str이고, "^[0-9a-zA-Z]{1,5}$"만 허용한다고 해 보겠습니다. 이것은 대소문자나 숫자로만 이루어진 길이 1에서 5 사이의 문자열만 허용한다는 의미입니다.

 

 post /res 요청이 날라왔을 때 불리는 메서드는 위와 같습니다. 이제 post /res 요청을 날려보겠습니다.

 

 

 문자열 "12-45"를 보내보겠습니다.

 

 

 그러면, 정규식에 맞지 않기 때문에, 422가 떨어지게 됩니다.