백엔드 crud 1번째 과제이다.
스벅 사이트의 메뉴-음료 카테고리를 일전에
erd 다이어그램으로 그려보는 과제가 있었는데
그걸 토대로 직접 db를 만들고 테이블을 만든 후
몇 가지 샘플값을 넣어보는 과정이다.
erd 다이어그램의 유용성은 이번 과제를 통해 깨달았는데
당시에 진짜 너무 이해가 안 갔었다.
나누는 법도 잘 모르겠고 어떤 기준으로 묶어야 하는지
트리는 어떤 구조가 돼야 하는지
그런 개념이 아예 머릿속에 없어서 진짜 남들 슥슥 의견 내고
잘 그려나갈 때 멘붕이 왔었다.
밤새서 기본 개념 정도는 숙지하고 남이 만든 거 보면
이해할 정도는 되었지만 아직도 스스로 그려보라고 하면
잘 못하겠다. 연습이 많이 필요할 것 같다.
아무튼 이번 작업 순서도를 정리해 보자.
가상환경 세팅 및 개발 준비는 저번 블로그 자료로 대체한다.
그 이후 작업 내용이다.
-
AqueryTools로 제작된 다이어그램 모델링을 참고해서
models.py에 class를 제작.
one to one, one to many, many to many 관계를
class로 구현할 수 있어야 한다. -
데이터베이스 생성
-
models.py 마이그레이션과 마이그레이트를 통한
데이터베이스 테이블과 각 칼럼 생성. -
파이썬 쉘을 이용, 각 테이블에 정보값 등록.
-
데이터베이스에서 입력된 값 확인.
-
현재 작업 브랜치에서 메인 브랜치로 pull request
이와 같은 순서로 작업을 진행했다.
특히 3번에서 엄청난 오류를 만나서 토요일 하루 종일 삽질하다가
결국 해결이 되지 않아 전부 밀고 새로 진행했다.
오류의 내용은 정말 다양했는데 가장 기억에 남는 건
마이그레이트 실패였다.
바뀐 내용이 없기에 마이그레이트 할 수 없다는 게 이슈였는데
별에별 걸 다 해 봤지만 다 안 됐다.
원인은 로컬에서 지워도 데이터베이스에 이미 한번 등록된 스키마에 대한
이력이랄까? 그런 내용이 남아 있기 때문에
fake를 통한 마이그레이트를 하면 된다고 돼 있었지만
모조리 실패하고 결국 싹 다 밀고 기초 세팅부터 진행했다.
실패를 해결했어야 내 자양분이 되는 건데 이건 뭐 시간만 버려서 아쉬웠다.
이런 형태로 클래스를 만들었다.
models.py에서 제작된 걸 마이그레이션 하면
sql이 알아먹을 수 있는 형태로 소스가 변경되는데
이러한 작업을 ORM이라고 한다.
파이썬과 db라는 전혀 다른 두 녀석들이 서로 호환되도록
중간에서 컨트롤해 주는 게 바로 ORM이며 장고가 이 기능을 제공하고 있다.
한 가지 주의해야 할 건
클래스명이 데이터베이스의 테이블명이 되는 건 아니다.
아래 meta 클래스 항목에 기재되는 값이 테이블 이름이 된다.
각 클래스에 들어가는 속성값들은 하나하나가 각 테이블의 칼럼이 된다.
이곳에서 일대일, 일대다, 다대다 설정을 할 수 있는데
포린키를 이용해서 만들 수 있다.
내가 어딘가에 속해 있다면 대상이 되는 테이블의 pk 값을 id로
가지고 있으면 된다.
만일 가장 상위의 메뉴 항목 아래에 카테고리 항목이 있다면
메뉴 클릭시 여러 카테고리가 나오게 되는 일 대 다의 관계가 되는데
이때 카테고리에 포린키를 만들고 메뉴 항목의 pk 값을 참조하면 된다.
이 부분에 좀 헷갈리는 개념이 있어서 마지막에 다시 정리할 예정이다.
modelys.py 작성이 끝났다면 마이그레이션을 해야 한다.
python manage.py makemigrations 앱이름
마이그레이션은 모델에 대한 변경 사항을 디스크에 저장하는 방법이다.
이 자체로 데이터베이스에 들어가는 것은 아니다.
마이그레이션이 문제 없이 진행되었다면 다음은 마이그레이트를 할 차례다.
마이그레이션을 통해 나온 파일을 데이터베이스에 넣는 작업을
마이그레이트가 한다.
python manage.py migrate
이 과정에서 무수히 많은 오류, 꼬리에 꼬리를 무는 오류를 경험했는데
검색하고 적용해 보고 하는 과정이 너무 복잡해서
따로 적어놓질 못했다.
중요한 건 결국 해결을 못하고 다시 싹 밀고 새로 했다......
마이그레이트는 변경된 작업이 없다면 적용되지 않는다.
마이그레이트가 끝나면 데이터베이스에 클래스로 작업해 놨던
테이블과 칼럼들이 생성됨을 볼 수 있다.
mysql -u root -p
show databases; # mysql에서는 세미콜론을 꼭 붙여줘야 한다.
use 데이터베이스명
show tables;
이제 파이썬 쉘에 들어가 생성된 테이블에 값을 넣어보자.
python manage.py shell
C.R.U.D에서 C의 과정인 create 작업을 해 보자.
Product.objects.create()
이런 형태의 명령어를 사용한다.
클래스명을 맨 앞에 써주면 되는데 대소문자 구분을 안 하면
오류가 발생하니 주의해야 한다.
products 테이블에 자료 넣는 예시
Product.objects.create(korean_name="아이스 아메리카노", english_name="Ice americano", description="님이 아는 바로 그 맛!", Category_id=1, Nutrition_id=2)
자료를 넣고 mysql에 접속해 select * from 테이블명으로 로 확인하면
방금 넣은 값이 잘 들어가 있음을 볼 수 있다.
이때 테이블명은 meta 클래스에 작성했던 이름으로 써야 한다.
SELECT * FROM products;
나는 테이블에 데이터를 넣을 때 Category_id=1, Nutrition=2
이런 식으로 참조할 테이블의 pk 값을 직접 넣어서 연결했는데
다른 분들 작업한 걸 보니 대부분
변수에 집어넣고 데이터 넣을 땐 해당 변수를 넣는 식으로 처리한 걸
볼 수 있었다.
내가 뭔가를 잘못한 건지, 그 차이점을 아직 모르겠어서
해당 부분은 공부를 더 하고 아래에 추가해서 작성할 예정이다.
일단 database의 table에 데이터를 모두 넣었다면
git push를 통해 깃허브에 올려주면 끝이 난다.
다만 과제에서는 현재 브랜치에서 main 브랜치로
pull request 하는 과제가 남아 있어 그건 별도로 진행했다.
깃허브 사이트 pull request 메뉴에 가면
main <-- 현재 브랜치
이렇게 고를 수 있고 new pull request 버튼을 눌러
pr을 진행할 수 있었다.
파이썬 쉘에서 데이터베이스에 데이터 넣을 때
내가 쓴 방식도 문제가 없다.
나는 참조할 테이블의 pk 값을 직접 입력하는 방식이고
다른 분들은 get을 이용해 참조할 테이블의 값을 불러와 변수에 넣고
해당 변수를 포린키를 지정한 현재 테이블의 속성값으로 넣어서
참조하는 방식의 차이다.
다만 테이블이 많아지고 복잡해질수록
참조할 테이블의 Pk 값을 일일이 찾아서 작업하는 건
get을 사용하는 방식보다 효율이 떨어지기 때문에
get을 이용하는 방식을 권장하는 것 같다.
이 부분은 아직 체감이 되지 않으므로
추후 프로젝트 등 진행하면서 몸으로 느껴봐야겠다.
