데이터 모델링 하다가
답이 안나와서 적어보는 TIL(This week I Learned.. or 그 이상..)
너무 밀려서 순서도 기억도 잘 없다는 것이 아쉽.
이 에러를 만난 것은 local DB를 덤프하여 원격 RDS에 import 하려고 했을 때. 아마도 collate 값이 일치하지 않아 발생하는 에러인줄 알았으나 답은 column_statistics
을 0으로 설정하고 다시 임포트하는데에 있었다. 참고한 블로그가 정말 많은데 지금 현재 창으로 남아있는 블로그는 이 곳.
다시 한 번 느꼈는데, 에러 메시지 잘 읽는게 제일 장땡이다. mysql 에러는 진짜 너무 지독하게 에러 메시지가 터미널에 후라라라락 떠서 읽기 싫어서 대충 본게 공수를 늘렸다는 서늘한 이야기.
reference: https://jay-ji.tistory.com/62
위도, 경도 값을 데이터로 받아 해당 위도, 경도의 위치 지점을 만들고 그 이후 다른 지점과의 거리를 산출하는 훌륭한 라이브러리.
reference: https://mizykk.tistory.com/21
확실히 일을하다보니 위코드에서 프로젝트할 때 이해할 수 없던 브랜치 개념이나, 브랜치를 새로 따야하는 시점에 대한 이해가 확실해진다. 그러나 아직도 여전히 사용한 브랜치를 지우는 것이(깃헙에 머지 시 친절하게 버튼이 있다 CLI가 아니라 GUI로 해결할 수 있는) 익숙치 않아, 한번에 후두둑 지워야했다.
reference: https://backlog.com/git-tutorial/kr/stepup/stepup2_5.html
우선 쿼리 성능 개선을 하기전에는 어느 곳에서 대체 병목이 발생하는지를 확실하게 파악해야하는데,
ORM을 shell에서 str([쿼리셋].query)
를 이용해서 raw query로 전환 후, raw query단에서 직접 쿼리를 날려보며 join하여 캐싱하는데 걸리는 시간을 파악해야 한다.
reference: https://django-orm-cookbook-ko.readthedocs.io/en/latest/query.html (str()[쿼리셋].query))
http://blog.naver.com/ddorai08/221681354652 (raw query 시간 계산)
장고 쿼리 개선에 대해 공감한 글 https://daeguowl.tistory.com/156
앞으로 참고하게 될 것: https://this-programmer.com/entry/django%EC%97%90%EC%84%9C-object-queryset%EC%9D%84-%EC%97%AC%EB%9F%AC-%EA%B8%B0%EC%A4%80%EC%9C%BC%EB%A1%9C-ordering%ED%95%98%EA%B8%B0-object-filter%EC%9D%98-orderby-%EA%B8%B0%EC%A4%80%EC%9D%84-%EB%8F%99%EC%A0%81%EC%9C%BC%EB%A1%9C-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0 (order_by 기준 동적 설정)
https://github.com/django/django/blob/fea9cb46aacc73cabac883a806ccb7fdc1f979dd/tests/prefetch_related/models.py#L218-L236 (위코드 동료가 추천해준 방식인데 적용을 실제로 아직 못해본 방법)
그냥 컬럼 값으로 정렬했을 때 치명적인 문제가 이런 것이다. 만약 Serial number가 H1부터 H1000까지 있다고 치면, 똑똑한 사람은 H1, H2, H3, H4 ... H997, H998, H999, H1000형식으로 정렬되는 것이 인지상정이라고 생각을 할 수 있지만 컴퓨터는 그렇지 않다. 이놈은 H1, H10, H100, ... 뭐 이따위로 정렬을 해버린다. 전혀 필요가 없음! 그래서 찾았다. 인간의 방식으로 정렬하는 방법.
reference: https://mo0nbox.tistory.com/96 (먹힌 방법)
https://sway.tistory.com/entry/MySql%EB%AC%B8%EC%9E%90%EC%97%B4-%EC%84%9E%EC%9D%B8-%EC%88%AB%EC%9E%90-%EC%A0%95%EB%A0%AC (이번에는 먹히지 않았지만 나중에 참고할 수도 있는 방법)
reference: https://stackoverrun.com/ko/q/4504318
AWS의 문제는 GUI나 CLI나 그냥 아직 너무 어색하다는 것이다. 모든 것에서 쫄게되는데, 내가 당장 매일 야근하고 있는 이 프로젝트 마무리하자마자 AWS 이자식부터 잡을 예정이다. 해보면 별거 없다.
reference: https://jootc.com/p/201809271876
JsonResponse 쏴주기 전에 정렬 기준이 필요해서 사용했다.
reference: https://rfriend.tistory.com/473
TextField의 default 값은 당연히 0이 아니라 None이다.
이거 진짜 여러번 화가나게 했음. 내가 아는 대로라면
1) models.py 수정 or 작성 시 python manage.py makemigrations
2) python manage.py migrate
3) applied OK... 뭐시기 뜨면서 모델 적용 및 DB 테이블에도 적용 완료인데,
적용할 것이 없는걸? 🥳 하면서 장고가 진짜 사람을 너무 약올리는 것이다. 그럴 때 해야하는 일이 있다. --fake 옵션! 동료 백엔드 개발자는 이에 대해서 '멍청한 장고놈을 속여서 migration하는 일'이라고 표현했다. 참고로 이 작업을 할 때에는 새로 작성한 models.py 부분에 주석을 걸어서 실행했다가, 다시 주석을 풀고 원래대로 작업해야 한다.
reference: https://stackoverflow.com/questions/46772762/django-migrate-fake-and-fake-initial-explained
역참조 시, prefetch_related로 해결보려고할 때, 그런 테이블 찾을 수 없다는 장고의 가혹한 메시지를 보게될 때는 Models.py에서 related_name을 걸어서 해결을 보았다.
이거 진짜 이상했다. 파이썬 내장 함수로 max(), min()이 있는데 왜인지! 대체 왜인지!! 안먹히는 것이었다. 정말 이해가 되지 않아서 이것저것 해보다가 이 블로그에서 시키는대로 해봤는데, 내가 직접 작성한 함수로는 또 적용이 되는 것. 대체 뭔일이란 말임?
reference: https://appia.tistory.com/137
11월에 해야만 하는 일
(그만 미루샘)
- 점프 투 파이썬 하루만에 끝내기
- Two Scoops of Django 2주에 끝내기
- AWS 서적 3주에 끝내기 (꼼꼼 정리 필요. 참고: https://www.44bits.io/ko/post/first_actions_for_setting_secure_account)
- 위코드의 좋은 동료 BJ의 CS 지식 블로깅 탐독하며 저자에게 질문하기 (https://velog.io/@kbj7227)
- select_related, prefetch_related로도 해결되지 않는 쿼리 성능 문제 해결 후 블로깅하기
- Pycon 장고 부분 리뷰할 것 (참고: https://goodlucknua.tistory.com/69)
후 정리했는데 그 때 그 때 했으면 얼마나 더 좋았을까!
11월은 더 알차게 보내자~!!!!! 나 화이팅~~