728x90
반응형

urls.py does not appear to have any patterns in it


  • 발생 이유 : 습관적으로 urls.py만 생성하고 안에 아무것도 작성하지 않아서 include()할 때 에러 남
  • 해결 : 안에 urlpatterns 작성
  • 반성 : 꼼꼼히 하자… 저번 프로젝트도 오타같이 사소한 에러로 몇 시간씩 날려먹는 걸 그렇게나 자주 하고도 아직도 덤벙덤벙

WSGI application “OIL_PAINTING.wsgi.application” could not be loaded;


  • 시도해본 것 : 경로 문제라는 이야기가 많았으나 따로 폴더를 만들지 않았으므로 경로도 이상무, middlewear에 whitenoise 어쩌구도 없고… 뭘까… 프로젝트 이름을 바꾼 적도 없는데에… 패키지 깔앗다 지웠다 경로도 바꿔보고 별 짓을 다해봤다.
  • 이름을 바꾼 적이 없는데 왜 저런 게 있었는지는 모르겠으나… OIL_PAINTING에 “_BE”를 추가해줬다. 프로젝트 생성 후 저 쪽은 건드리지도 않았는데 왜 저렇게 됐는지 아직도 미스테리. 그래도 해결하려고 구글링하는 과정에서 wsgi.py가 제대로 작동하기 위해선 settings.py에 경로가 제대로 작성되어 있어야 한다는 걸 알게 되었다.

expected string or bytes-like object


정규표현식을 활용해 유효성 검사 실시하다 발생

  • 시도해본 것 : 구글링 해보니까 문자열이 아니라서 발생한 문제라길래 type()을 해봤는데 문자열 맞고, 굳이 type() 안 해도 누가 봐도 따옴표로 감싸져 있고, str()도 써봤으나 안 되길래 뭐지… 에러 이유도 명확한데 뭐지? 했는데 내가 바보였다. 정확히 말하면 정규식이 문자열이 아니어서 발생한 문제가 아니고 “데이터”가 문자열이 아니어서 발생한 문제라서 정규식이랑 비교할 데이터에 str()를 써서 해결했다.
  •  
# 수정 전
if not re.search(email_reg, email) :
    raise serializers.ValidationError(detail={"email":"이메일 형식에 맞춰서 작성해 주세요."})

# 수정 후
if not re.search(email_reg, str(email)) :
    raise serializers.ValidationError(detail={"email":"이메일 형식에 맞춰서 작성해 주세요."})

got attributeerror when attempting to get a value for field password_check on serializer userserializer


  • 에러 : 에러 이유는 나도 모르지 않았다… 에러 메시지 수정하려고 유저 시리얼라이저에 필드 만들어 놨는데 유저 모델에 없으니까 문제가 생겼겠지… 아무래도 모델 참고는 User로 하는데 거기 없는 필드를 쓰는 유저 시리얼라이저로 갖고 와서 필드를 만들었으니…
  • 시도해본 것 : 그냥 문제가 되는 코드를 없앴다. 처음에 몇 시간동안 만져도 되질 않아서 문제가 되는 password_check 코드랑 fields를 지우고 fields를 __all__로 설정했다. 근데 너무 킹 받아서 시리얼라이저를 따로 파면 될 것도 같은데… 근데 딱 봐도 너무 비효율적이고 다른 방법이 있을 거 같은데… 하다가 일단 넘겨놨다가 너무 신경쓰여서 고치기로 마음 먹고 삽질하다가 안 돼서 튜터님한테 갔다… 아 안 적을 뻔했네 SerializerMethodField도 써볼까 했는데, 애초에 id, profile_img, followings 등 해당 유저에 대한 여러 데이터가 필요해서 UserSerializer로 가지고 온 거라서 쓰려다가 말았다.
  • 해결 : write_only 써서 못 읽게 만들어서 해결.
  • password에 직렬화 시키지 말라고 write_only 써놓고 왜 여기에는 쓸 생각을 몬했지?????????????????
  • 알게된 것 : 왜긴 왜야 대충 알고 제대로 몰랐으니까 그랬겠지. write_only 여부에 따라 시리얼라이저가 필드를 어떻게 다루는지 좀 와닿게 됐다. 그리고 이 에러 해결은 고대로 다음 프젝 유저 모델 준비할 때도 잘 쓰이게 된다. ((사골))
# 유저 시리얼라이저 일부
class UserSerializer(serializers.ModelSerializer):
    password_check= serializers.CharField(error_messages={'required':'비밀번호 확인까지 입력해 주세요.', 'blank':'비밀번호 확인까지 입력해 주세요.'}, write_only=True) 

    class Meta:
        model = User
        fields = ("nickname","password","mbti","profile_img", "password_check")

# 프로필 시리얼라이저 일부
class ProfileSerializer(serializers.ModelSerializer):
    followings = UserSerializer(many=True)  # 사용자가 팔로우하는 사람들
    followers = UserSerializer(many=True)  # 사용자를 팔로우하는 사람들

    article_set = ArticleSerializer(many=True) # 사용자가 작성한 게시글
    comment_set = CommentSerializer(many=True) # 사용자가 작성한 덧글들
    movie_set = MovieListSerializer(many=True) # 사용자가 좋아요 한 영화

    class Meta:
        model = User
        fields = '__all__'

이론 복습 및 궁금증 해결


  1. 참조 무결성 원칙
    • 처음 이해한 바 : OTM 관계에서 Many가 외래키로 가져오는 필드는 ONE의 PK 필드여야 한다.
    • 궁금했던 것 : 그럼 on_delete 속성 줄 때 속성값이 PROTECT면 원칙을 무시하는 거 아닌가??? 유저 데이터가 삭제돼도 게시글 데이터는 남아있는데????
    • 알게된 것 : 가령 on_delete=PROTECT는 유저-게시글 관계에서 유저 데이터를 지우면 참조 무결성 원칙에 위배되지 않도록 유저 데이터를 보호하는 거고, set_null 속성은 유저 데이터가 Null로라도 존재할 수 있도록 만드는 것이다. 즉 참조 무결성 원칙이란 쉽게 말하면 참조되는 데이터가 어떤 형태로든 존재해야 한다는 것. 틀린 게 있다면 지적 및 조언 환영합니다 지나가는 인터넷 유저 분ㅎㅎ
  2. selected_related랑 prefetched_related
    • 궁금했던 것 : selected_related가 정참조일 때 쓰는 건 알겠는데, prefetched_related를 역참조일 때만 쓴다는 건지 역참조일 때도 쓰고 정참조일 때도 쓴다는 건지 헷갈렸다.
    • 잡담 : 그래서 prefetced_related 둘 다 되는 건 맞지만 실질적으로 selected_related가 정참조일 때, prefetched_related가 역참조일 때 쓰인다고 생각해도 되냐고(이렇게 결론지으려던 건 아니었다. 뭔가 이런 식으로 공식화하는 건 스스로도 좋아하지 않는다. 경향성을 알고싶었을 뿐.) 물었는데, 다시 한 번 정참조일 때 selected_related를 “쓸 수 있는 상황이라면” selected_related를 사용해주는 게 좋다고 말씀해주신 걸로 보아 정참조인데 selected_related를 쓰지 못하는 경우가 있는 건가 싶었다.
  •  

오늘 하루를 마무리하며


  • 팀 회의와 프로젝트 준비를 하며 공부는 사실상 거의 못했다.
  • 팀 회의 하고 프젝 전에 erd랑 api 명세, 와이어 프레임 러프하게 잡아놓고 내일 발제 끝나고 완성해서 s.a. 제출하기로 했다.
  • 오늘 프젝 전인데 TIL에 트러블슈팅 꽤 해놨으니까 러프하게 잡아놓은 s.a. 자료들은 생략하겠다. 내일 최대한 최종 결과물이랑 바뀌는 게 많이 없도록 철저하게 만드려고 노력하겠지만 아직 미숙해서 그런지 어차피 최종이랑 안 맞더라. 프로젝트 끝나면 그 때 올릴 예정
  • 유저 모델 유효성 검사까지 해서 넣어놨다. 어제 유지보수 하면서 만져봐서 난이도 갠춚!
반응형

'Programming > TIL and WIL' 카테고리의 다른 글

🐻 221123 Today I Learned 🐻  (0) 2022.11.23
🐻 221122 Today I Learned 🐻  (0) 2022.11.22
WIL  (0) 2022.11.21
💖221120 Today I Learned💖  (0) 2022.11.21
221118 TIL… 이라기보다는 주저리 주저리  (0) 2022.11.19

+ Recent posts