23.01.18 [@OnDelete]

원하는기능 
[[,,,],[,,,],[,],[,],[,,,]] 요렇게해서 셀러가 쓴 게시글에 해당 하는 요청이 담기게..
이럴라면... 셀러아이디가 필요해 ~ ㅠㅠ 아니면 postid받아온거에서 post객체 꺼내고 셀러아이디 꺼내는걸
임시방편으로 사용하자

//지금 든 생각 1
 // 1.유저이름으로 보드레포 들려서 해당 유저가쓴 게시글 다 리스트로 가져옴
 // 2. 이걸 for-each돌려서 getID해서 Long타입을 꺼내 ~
 // 3 그러면 꺼낸 id를 이용해서 요청포지토리에 들려서 list<요청> 이렇게 담아옴
 // 4.list<요청> 담아온걸 다시 List<list<요청>> 에 담아줘서 반환해줌 !! 일단 이렇게 다시 구현해보자 ..!

---

 

properties.sercet 하나만든다

그리고 거기에 민감한 보안 정보를 ex) jwt.secret.key 를 보관하고

 

.gitignore...

https://jiyongyoon.github.io/ide/properties-gitignore/

[IntelliJ] 깃허브에 민감정보(properties) 올리지 않는 방법

---

 

https://gilssang97.tistory.com/70

Cascade의 오해

 

https://gilssang97.tistory.com/71

Cascade vs @Delete

 

 

약간 쓰면좋을듯 하면서도 뭔가.. 뭔가다...

 

---

연관관계 편의 메소드

 

 

양방향보다 ..단방향 해야되는 이유는 

• 관리해야할 포인트가 늘어난다.
• 이전에 언급했던 것처럼 단방향 매핑으로도 충분히 표현이 가능하다.
• 롬복의 @ToString, @EqualsAndHashCode 등을 사용하는 경우 서로의 무한 참조로 인한 스택오버플로우 발생 가능성이 존재한다.

 

@Delete

@Delete는 DB에서 처리해주기에 단일한 쿼리를 통해 연쇄적으로 제거할 수 있지만 Cascade의 경우에는 여러개의 쿼리를 날린다.

그렇기 때문에 @Delete가 효과적으로 보일 순 있으나 on delete cascade에 의해 어떠한 레코드의 참조 레코드까지 연쇄적으로 삭제해버릴 수 있는 여지가 존재한다는 단점이 존재한다.

---

@ResponseBody는 두개 달면안된다 ..!