일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- on_delete
- nodeJS
- Jest
- pm2
- westagram
- node
- TypeError: this.boardRepository.createBoard is not a function
- CORS
- 자바스크립트
- 장고초기세팅
- 호이스팅
- async/await
- Django
- OSI7계층
- manytomanyfield
- 트랜잭션
- crud2
- 스코프
- 프로미스
- javascript
- 실행 컨텍스트
- rebase
- typescript
- bcrypt
- wecode
- JWT
- status code
- docker
- 노드
- django westagram
- Today
- Total
될때까지
((TURTLE HOME)) 프로젝트 코드 살펴보기 본문
🔍 auto_now_add and auto_now
class TimeStampeModel(models.Model):
created_at = models.DateTimeField(auto_now_add=True)
modified_at = models.DateTimeField(auto_now=True)
class Meta:
abstract = True
created_at 생성일시는 DateTimeField의 auto_now_add속성을 True로 적용했고
modified_at 수정일시는 DateTimeField의 auto_now속성을 True로 적용했다.

장고 공식문서를 살펴보면 왜 이 둘을 다르게 적용했는 지 알 수 있다.
- auto_now는 객체가 저장되는 현재 시간을 저장한다.
- auto_now_add는 객체가 처음 생성된 시간을 저장한다.
🔍 on_delete
class Category(models.Model):
name = models.CharField(max_length=50)
class Meta:
db_table = 'categories'
class SubCategory(models.Model):
name = models.CharField(max_length=50)
image_url = models.CharField(max_length=500)
category = models.ForeignKey('Category', on_delete=models.CASCADE)
class Meta:
db_table = 'sub_categories'
SubCategory 클래스를 정의하고 category를 외래키로 연결했다.
이 때 on_delete 옵션을 CASCADE로 적용했었다.
Django에서 테이블을 서로 연결할 때 ForeignKey를 사용해서 연결했다.
이때 on_delete 속성을 통해서 참조된 값을 삭제할 때 연결된 데이터들은 어떻게 처리할지 정할 수 있다.
- CASCADE : 참조값이 삭제되면 같이 삭제한다.
- PROTECT : 참조값을 삭제하려고 할 때 삭제하지 못하게 ProtectedError 일으킴
- RESTRICT : 참조값 삭제 안되지만 특별한 상황에서는 가능함
- SET_NULL : 참조값이 삭제되면 외래키값을 null로 변경(null=True필수)
- SET_DEFAULT : 참조값이 삭제되면 외래키값을 미리 설정해둔 default값으로 변경(default=True필요)
- DO_NOTHING : 참조값이 삭제되도 아무것도 하지않음(참조무결성을 해칠 위험 있음)
참조무결성? 기본키와 참조키간의 관계가 항상 유지되도록 보장하는 것을 말한다.
=> SubCategory의 외래키로 연결한 Category가 삭제되면 Subcategory의 category row도 삭제한다.
🔍 get_or_create
cart, is_created = Cart.objects.get_or_create(
user = user,
product_option = product_option
)
cart.quantity += quantity
cart.save()
status = 201 if is_created else 200
return JsonResponse({'message' : 'SUCCESS'}, status=status)
get_or_create를 사용하면 객체가 존재한다면 해당 객체를 반환하고, 존재하지 않는다면 객체를 생성한다.
해당 메소드는 (object, created)를 튜플 형식으로 반환하며 created에는 boolean flag가 담긴다.
즉 DB에서 해당 객체를 찾았다면 (object, false)가 반환되고 객체를 생성했다면 (object, true)가 반환된다.
따라서 is_created가 true인 경우는 객체가 생성된 상황이니까 장바구니에 새로운 데이터가 생성됬다는 걸 의미한다.
이를 이용해서 is_create가 true라면 새 객체 생성이니까 201을 반환, 그게 아니면 200을 사용해서 업데이트 처리를 해줬다.
🔍 ERD

1차 프로젝트 ERD에서 이해가 안가던 부분이 있다. 왜 굳이 ProductOptions테이블을 따로 빼서 진행했는지 이해가 안갔다.
그냥 Products테이블에 옵션이름이랑 사이즈랑 가격을 넣어주면 로직을 작성할때도 한번에 DB에서 조회가 가능하고 편리하지않을까?
이해를 위해 예시를 그려봤다.

예시로 그냥 상품옵션테이블에 사이즈 이름만 합쳐봤다. 여기서 '싱글'로 정의했던 부분이 'single'로 바뀌게 된다면..?
'single'이라는 값을 가지고 있는 있는 모든 상품들의 데이터를 일일이 변경해줘야하는 번거로움이 생긴다.
반면에 위처럼 size의 테이블을 따로 만들어서 size테이블의 id를 참조했다면 기~냥 싱글 이름값을 single로 바꿔주면 끝이다.
그렇군. 데이터의 유지보수가 쉽고 확장성을 위해서 ERD를 나누는 게 편하다고 이해했다.
* 참고자료 => 장고 공식문서
'프로젝트 > wecode1차 : TURTLE-HOME' 카테고리의 다른 글
((TURTLE HOME)) 프로젝트 배포해보기 (0) | 2022.07.31 |
---|---|
((TURTLE HOME)) 위코드 1차 프로젝트 회고록 (0) | 2022.07.30 |
((TURTLE HOME)) 11일차 : ProductListView filtering refactoring (0) | 2022.07.30 |
((TURTLE HOME)) 10일차 : ProductListView filtering(price) (0) | 2022.07.28 |
((TURTLE HOME)) 9일차 : ProductListView filtering(size) (0) | 2022.07.27 |