일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- TiL_1st_0419
- 스파르타내일배움캠프
- #내일배움캠프
- 인스턴스
- 감사기록
- 해우소
- Diary 해우소
- #스파르타내일배움캠프
- Token
- 성장기록
- 클래스
- Java
- 내일배움캠프
- 메서드
- Git
- #스파르타내일배움캠프TIL
- JVM
- KPT
- diary
- Github_token
- 스레드
- 스파르타내일배움캠프TIL
- 변수의 다양성
- 객체지향 언어
- GitHub
- 포맷은 최후의 보루
- 회고록
- static
- 생성자
- Java의 이점
- Today
- Total
몬그로이
프로젝트 8일차 본문
좋아요 테이블 설정
like_id | 좋아요 id |
user_id | 유저 id (좋아요 누른 유저) |
content_id | 게시글or댓글 |
content_type | 컨텐츠 타입 |
created_at | 좋아요 등록 시간 |
라고 설정이 되어있는데 문제는 content_id 이다
게시글과 댓글을 모두 넣을 것인데, content_id 하나로 통합해서 받는다면
중복되는 id 가 있을 것이고, 나중에 분명 문제가 될 것이다
따라서 좋아요를 두 개로 분리하기로 했고
컨텐츠 타입을 이름에 명시하기로 했다
이렇게 하는 게 좋다고 생각한 다른 이유로는,
게시글이나 댓글에 비해 좋아요 수는 배로 많을 것이기 때문에
같이 두면 나중에 조회할 때 한참 걸릴 수 있기 때문이다
나중에 말씀드려봐야지 하고 있었는데
같은 팀원분께서 말씀하시길
content_id 를 둔 이유가
like 아이디를 토큰에 저장시켜서 눌렀는지 안 눌렀는지 확인하는 방식이라고 했다고 한다
아무튼 그런 상황이면 like_id 는 like 테이블에 있을 필요가 없는 상황인 것 같은데,
팀장님이 부재중이라 물어볼 수 없는 상태다
트러블슈팅 11:00 ~
MySQL 테이블 생성이 되지 않는 문제
pull 받아온 것을 머지하는 과정에서
jpa:
hibernate:
ddl-auto: update
properties:
hibernate:
show_sql: true
format_sql: true
use_sql_comments: true
라고 되어있어야 하는 것이 (hibernate 두 번)
jpa:
properties:
hibernate:
ddl-auto: update
show_sql: true
format_sql: true
use_sql_comments: true
라고 되어있었기 때문이었다 (hibernate 한 번)
연관관계 설정이 헷갈린다
artistGroup 이 생성되면 유저들이 사용하는 커뮤니티와, 아티스트가 글을 쓸 수 있는 게시판 같은 곳이 생성되는데,
그렇기 때문에 게시판에 연관관계가 맺어지는 것은 artistGroup 뿐이며
artist 는 게시판에 직접 연관관계 설정이 되지 않는다
게시글 CRUD 의 검증 로직을 어떻게 할지 고민하는 동안
팀원들은 계속해서 오류를 고쳐나갔다
전체 조회는 page 인지 List 인지 아직 모르겠어서 일단 제쳐두고 머지 후 정상작동하여 push해 두고 오늘은 끝!
새벽 4시부터 장장 18시간 - 식사시간&존 시간 = 15시간쯤?
좀 쉬었다가 마저 해야겠다
'Dev입성기' 카테고리의 다른 글
팀프로젝트 9일차 (0) | 2024.07.26 |
---|---|
프로젝트 8일차 (0) | 2024.07.25 |
그 날 만은 아팠으면 (1) | 2024.07.24 |
그렇게 만들어! (1) | 2024.06.13 |
팀프로젝트 진행 기록 3 ~ 4일차 (1) | 2024.06.07 |