- 기본적으로 붙는 애노테이션
- @Entity, @Getter
- @NoArgsConstructor(access = AccessLevel.PROTECTED)
: Setter를 지양하기 때문에 로직상으로는 필요 없지만, 엔티티에는 기본적으로 기본 생성자가 필요합니다.
- @Table(name = “테이블이름”)
: 기본적으로 JPA가 만드는 테이블 네임을 사용하긴 하지만, Intellij 연동을 위해 작성합니다.
- @SQLDelete(sql = "UPDATE 테이블명 SET is_active = false WHERE id = ?"),
: JPA 상에서 delete 작동이 어떤 쿼리문을 날리는지 작성합니다.
soft delete를 사용한다면 보통 이렇게 사용합니다.
- @SQLRestriction(”is_active = true”) (spring 버전 3.2 이상)
@Where(clause = “is_active = false”)(spring 버전 3.1 이하)
: 이 어노테이션은 전체적으로 is_active가 true인 데이터를 베제합니다.
삭제되더라도 예외적으로 데이터에 접근할 수 있도록 하기 위한 soft delete의 의도와는 상충됩니다.
사용 지양하길.
- private 생성자와 @Builder 어노테이션을 사용합니다.
: 최대한 예측 가능한 객체(불변객체)를 만들고, 가독성이 좋은 Builder 패턴 사용을 강제하기 위함입니다.
- @AllArgsConstructor를 안쓰는 이유는 is_active와 같이 직접 지정하면 문제가 발생할 수 있는 필드들을 제외하기 위해서입니다.
(물론 가끔가다 생성자와 Setter를 사용하는게 “압도적으로” 편해서 사용하는 경우가 있긴 합니다. 이 기준은 코드 리뷰를 하면서 함께 판단해봅니다.)
- @~~ToOne의 매개변수로 FetchType.LAZY를 넣어줍니다.
: 지연로딩 최대한 활용
- 되도록 양방향 매핑을 지양하고 단방향 매핑을 지향합니다
: 무분별하게 양방향으로 매핑된 엔티티는 의도하지 않은 버그가 일어날 가능성이 농후합니다.
양방향으로 매핑을 하게 되면 두 엔티티 사이의 데이터 불일치가 발생하기 쉬워서
삭제를 했음에도 삭제가 되지 않는 상황 혹은 삭제를 하지 않았으나 삭제가 되는 상황이 발생할 수 있습니다.
추가적인 이유 참고 링크 : 인프런JPA 양방향 연관관계 관련하여 질문 드립니다. - 인프런 | 커뮤니티 질문&답변
- 만약 부모 엔티티에서 자식 엔티티를 조회할 필요가 있을 시에 Repository를 사용하여 조회합니다
chartRepository.findAllByGuardian(brand)
- 부모 엔티티에 속하는 자식 엔티티를 삭제할 시에도 Repository를 사용합니다.
chartRepository.deleteAllByGuardian(brand)