TIL 230705 : PK FK N:M 중간테이블 매핑하며 (해시태그 게시글 작성)

작업내용

 

 

 

 

 

 

 

오른쪽과 같이 Tag(HashTag에서 변경 : Post가 N:M 관계여서 중간에 받아주는 TagPostTable 중간테이블을 만들었다.

 

정리하자면 Post랑 Tag의 외래키를 갖는 TagPostTable Entity를 하나 더 만들고 맵핑하였다.

 

그러고 어김 없이 오류가 났는데 그로인해 배운 원칙을 정리하자면 아래와 같다.

 

 

 

 

 

 

 

 

 

 

 

---

배운점

1. FK를 가지고 있는 객체를 Repository에 저장할 때는 FK로 매핑된 객체들이 PK를 가지고 있어야 한다.

쉽게 말해, Tag와 Post객체의 각 PK를 FK로 가지는 TagPostTable 객체를 만들고 DB에 save할때 각 객체들이 PK값을 가지고 있어야 한다.

 

 

tagPostTable 객체를 DB에 저장하기 전이다.

아직 id(PK)값은 null이고, 그 안에 할당된 객체들의 PK값은 지정이 되어있다.

각 객체들(tag, post)들의 PK가 이제 FK로 저장되고 활용되는 셈이다.

 

그 이후에 save(); id에 PK값으로 활용될 Lond id 가 부여된 것을 확인할 수 있다.

 

지금에서야 너무나 당연하지만 처음 익히며 할 때는 저장을 하며 자동으로 PK가 같이 부여해준다고 착각했다.

 

 

2. DB상에는 문제가 없더라도 Spring안에서 조회가 되려면 객체를 넣어줌으로써 매핑해야 된다.

외래키의 주인인 tagPostTable은 Tag나 Post를 객체로서 가지고 있기 때문에 바로 접근할 수 있다.

하지만 Post가 Tag를 조회하려면 Post안에 TagPostTable을 넣어줘야 중간테이블을 통해 조회할 수가 있다.

 

Post Entity에 멤버로서 매핑되어있는 tagPostTable

(우) Post객체에 tagPostTableList 콜렉션에 id가 8인 tagPostTable객체가 할당된 모습.

왼쪽과 같이 Tag와, Post를 먼저 생성해 준 뒤, 해당 객체를 파라미터값으로 받아서 생성하는 생성자를 만들었고,

그 안에 연관관계를 넣어주는 코드를 추가했다.

 

 

3. Spring에서와 DB상의 각 컨벤션을 숙지하자

다시 말하자면, 각 컨벤션을 이해하고 혼용하지 말자. 혼용하면 못 알아 듣게 되고, 알아서 바꿔주지 못 한다.

Entity의 createdAt 변수명이 DB상에서는 자동으로 created_at으로 된다.

 

 

이걸 경험했던 우리팀은 초반에 Entity의 변수명부터 created_at과 같은 변수명으로 미리 지어두었다.

DB상에서는 문제가 없었는데, 쿼리메소드시 제대로 동작하지 않는 일이 생겼다.

 

 

언더바( _ )로 나뉘어진 부분까지 변수명으로 인식하여 제대로 동작하지 않았다.

 

관련된 멤버명과 메소드명 수정.

 

---

크고 작은 오류들을 겪으며 고통스러운 시간들이
추후에는 숙련됨으로 되길 바란다.