이번주 일월화수목 내내 새벽 네시~다섯시까지 뭔가를 두들겨보았다.
음 ... 이런 살인적인 스케쥴로 인한 가시적인 변화를 찾아보자면
... 눈에 띄게 건강을 잃은 것 같다.
가랑비에 옷 젖는다고 개발 실력도 늘어갔으면 좋겠다.
[mysql] dump 후 import는 truncate를 동반한다
어찌보면 너무 상식적인 이야기이겠지만, 이로 인한 실수가 날 수 있다.
정말. 날 수 있다. ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ
누구에게나 위험할 수 있는 이야기.... 후후
정말....... 지금이야 '후후' 하지만 진짜 ..... 후...........
넘나 아뜩하여 정신을 잃을뻔했다...ㅎㅎ......
조 심 또 조 심
[django] migration
models.py에 변화가 생길 때에 사용해야하는 명령어 python manage.py makemigrations
그리고 이 변화를 연결된 실제 DB에 적용할 때 사용해야하는 명령어 python manage.py migrate
이 둘만 있으면 무적이라고 착각한 때가 있었다. 얼마나 장고가 보수적인 놈인지 몰랐을 때에는.....
하지만 작업하다보면, 종종 장고를 속여야하는 때가 발생한다. 왜냐하면, 지가 생성해놓고도 테이블이 생성된 줄을 모른다거나 지가 생성한적도 없으면서 생성했는데 왜 또 만들라고 해? 라는 에러를 뱉기 때문에.
이럴 때 참조할 수 있는 사이트는 아래와 같다.
Table doesn't exist 발생 시:
https://stackoverflow.com/questions/27583744/django-table-doesnt-exist
Table already exists 발생 시:
https://antilibrary.org/911
테이블 지운 후, 다시 마이그레이션 하는 방법 (이 방법들은 실제 시도하지는 않았음):
https://sundries-in-myidea.tistory.com/84
[django] nonetype은 참조할 수 없습니다 에러 핸들링
django에서 return할 리스트를 만들 때에는, 어느 정도 사용할 데이터를 prefetch_related와 select_related로 미리 캐싱해두고 그 이후에 테이블을 넘나들며 실제로 필요한 값을 사용하게 된다.
그런데 만일, 이 과정에서 Nonetype을 참조하게 되면 nonetype은 참조할 수 없다는 에러가 뜨게 된다. 이러면 캐싱된 데이터를 사용할 수 없는건가? 그럼 성능은 어쩌지? 라는 생각이 들게 되는데, 이럴 때에는 방법이 다 있다. nonetype을 참조하게 될 가능성이 있는 데이터는 미리 리턴할 딕셔너리 안에 key값을 지정하지 않고, 딕셔너리 밖에(아래에) 따로 코드를 작성한다. if 'nonetype일 확률이 있는 테이블'.objects.filter(id=x).exists(): 로 해당 테이블이 nonetype인지 혹은 실값이 존재하는지를 먼저 파악한 후, nonetype이 아니라 실값이 있는 데이터일 때만 작동해야하는 코드를 작성해준다. 이렇게 하면 nonetype일 때에는 아예 코드 자체가 동작하지 않아 리턴할 값에 데이터가 들어가지 않을 뿐 에러를 뱉지는 않는다. 그리고 실값이 존재할 때에는 코드가 작동하여 내가 필요로하는 데이터를 끌어올 수가 있다.
[하드웨어] 트리플 모니터 사용 시작
그냥 무조건 이거는 써야한다. 더 이상의 설명이 필요 없음.
[django, mysql] Bulk Create vs. mysqlworkbench를 이용한 bulky data import
그동안 소규모의 데이터를 다룰 때에는 db_uploader.py를 manage.py 단에 작성하여, python db_uploader.py 로 데이터를 넣는 것이 크게 어렵지도 힘들지도 않았다. 하지만 데이터가 10만개, 20만개, 심지어 100만개가 넘어가니 .... 게다가 후에 효율적으로 캐싱하기 위해 index기능까지 심다보니 데이터 들어가는 속도가 현저히 느려졌고(20만개 기준 20시간) 이런 식으로는 도저히 물리적으로 많은 데이터를 다 넣을 수 없다는 판단을 했다.
BulkCreate시 참고한 블로그
: https://velog.io/@swhybein/Django-bulkcreate%EC%9C%BC%EB%A1%9C-csv%ED%8C%8C%EC%9D%BC-%EC%98%AC%EB%A6%AC%EA%B8%B0
(⛑ 이 블로그에서는 bulk_create 시, FK 연결이 불가능하다고 쓰여있지만(차후에 bulk_update로만 가능하다고 쓰여져있음) 나는 처음에 넣을 때부터 id를 이용하여 fk로 연결하였다.)
: https://wangin9.tistory.com/entry/django-bulk-insert
공식 문서:
https://docs.djangoproject.com/en/3.0/ref/models/querysets/#bulk-create
[django] select_related, prefetch_related 사용 시, () 속 이름
select_related(x) 혹은 prefetch_related(x)
이 때 x 자리에는 models.py에 정의한 클래스 이름을 소문자로 하여 넣는 것이 맞다.
이게 무슨 말이냐하면 ... select_related나 prefetch_related를 사용할 때에 이런 경우가 있다. 내가 models.py에 정의한 클래스 명은 Nhospital인데, db에 들어간 테이블명은 n_hospitals이다. 그러면 나는
select_related('nhospital')을 써야할지
select_related('Nhospital')을 써야할지
select_related('n_hospitals')를 써야할지
헷갈리는 상태가 되는 것이다... (실제 경험)
그런데 이번에 확실히 알았다. class명 기준으로, 모두 소문자로 쓰면 된다. 즉 이런 경우에는 select_related('nhospital')로 쓰면 된다. 만일 prefetch라면, prefetch_related('nhospital_set')이라고 적으면 된다.
[python] 삼항연산자
정말 간단하다.
[참일 때의 값] if [참일 조건] else [거짓일 때의 값]
이 간단한 식에서 else뒤에 :를 붙이는 바람에 실행이 안된 경험이 있다.
[python, django] python datetime vs. django datetime
python의 datetime 패키지를 사용하기 위해서는 from datetime import datetime을 쓰고, django의 datetime을 사용할 때에는 from django.utils import timezone을 쓴다. 이번 프로젝트에서는 실제 유저가 request를 보내는 때의 요일이 필요한 코드가 있었는데, 실시간 유저의 시각을 나타내기 위해 나는 먼저 python 패키지를 떠올렸고 코드를 짜봤다. 그러나 이내 django.utils의 timezone을 이용하면 훨씬 더 간편하고 확실하게(왜냐하면 django 기본 세팅을 UTC가 아닌 Asia/Seoul로 해두었기 때문. 그냥 파이썬 패키지를 사용할 경우 기본값은 UTC 기준으로 들어가지만, 장고 패키지를 이용하면 내가 설정해둔 시각에 맞추어 들어온다.) 원하는 값을 도출할 수 있음을 알았다. 하여 real_time_day = datetime.weekday(timezone.localtime()) 한줄로 실시간 유저의 요일을 알아낼 수 있었다.
참고한 블로그:
https://8percent.github.io/2017-05-31/django-timezone-problem/
[etc.] ipconfig 해서 나오는 내 고유 아이피로 로컬 서버 접속 시도할 때에는
python manage.py runserver 에서 끝내지 말고 뒤에 로컬 ip 주소를 붙여주어야 한다.
python manage.py runserver [ipconfig로 알아낸 나의 ip]
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/22) 해결할 수 있는 일은
--> 점프투파이썬(or Replit), BJ 블로그 탐독, AWS 클라우드와치 알아보기
select_related, prefetch_related에 관해서는 이제 드디어 감이 잡히는 느낌을 받고 있다. 아주 고무적이다. 곧 정리할 수 있을 것 같다.
일복 터지는 회사에 들어와서 너무 좋은 동료들과 함께 하루하루 정말 코피터지게 성장중이다.
정신 차려보니 연말이고 12월에는 더 바쁠 것 같다.
몸이 바쁘고 정신이 바쁜건 괜찮다. 그저 12월 31일까지 나의 유일한 목표인, '신입 백엔드 개발자'다워지기가 성공할 수 있으면 좋겠다.
