프로젝트 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시간쯤?
좀 쉬었다가 마저 해야겠다