일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- ...점점점문법
- indexOf()
- lastIndexOf()
- 리엑트블로거
- ubuntu타임존
- 시퀄 문법
- @Moditying @Query
- 레디스 확인
- js 문자열을 문자배열로
- 코딩 어?
- 객체의키값만 찾기
- 가상컴퓨터마법사
- sql like연산자
- 배열을 객체로
- findIndex()
- 문자열 인터폴레이션
- 5.3.8 Modifying Queries
- 스프링 데이타 JPA
- 객체를 배열로
- 프론트엔드 스쿨
- Robo3T 폰트변경
- Robo3T 글씨체 변경
- sql 문자열 패턴 검색
- ${변수}
- search()
- 깃 토큰 만료
- Robo3T 폰트 키우기
- 우분투 시간 변경
- 객체의 밸류값만 찾기
- Robo3T 글씨키우기
- Today
- Total
코딩기록
[JPA] nullable=false와 @NotNull 차이 ---펌 본문
nullable=false vs @NotNull
이 때, 내가 위 코드에 적은 내용 중 nullable = false 라는 내용이 있다.
nullable은 @Column의 속성 중 하나로, 기본값은 true이다.
값을 false로 설정해 주면, 해당 필드는 DDL 생성 시 not null이라는 조건이 붙은 채로 생성된다.
그런데, 누군가는 이런 생각을 할 수도 있겠다.
"저렇게 써주면 DB에는 null이 들어갈 수 없지만, 엔티티의 필드에 넣는 건 가능하니까 위험하지 않을까?
엔티티에 Spring Bean Validation을 써서 검증하면 어떨까?"
코드를 먼저 보자.
@Entity
public class Member {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(name = "email", nullable = false)
@NotNull
private String email;
}
어노테이션이 줄줄이 들어가니 보기가 힘들어진다!
그런데 여기서 알아낸 재미난 사실이 있다.
위 @Column에서 nullable=false를 제거해도, @NotNull이 붙어있으면 DDL 생성 시 not null로 생성된다는 것!!
이렇게만 써줬는데
이게 not null로 알아서 바뀌네?
이게 어떻게 가능할까? 다행히 이에 대해 다룬 포스팅을 찾았다.
여기에서 이에 대한 언급을 하고 있다.
How's that possible? As it turns out, out of the box, Hibernate translates the bean validation annotations applied to the entities into the DDL schema metadata. (...) However, if, for any reason, we want to disable this Hibernate feature, all we need to do is to sethibernate.validator.apply_to_ddlproperty to false. |
Hibernate는 엔티티에 적용된 Bean Validation 어노테이션 역시 DDL로 변환한다는 것!
만약 이 기능을 비활성화하려면, application.properties에 다음 한 줄을 추가하면 된다.
spring.jpa.properties.hibernate.validator.apply_to_ddl=false
인용한 글에서는, 결론적으로 nullable = false 보다 @NotNull을 추천하고 있다.
@NotNull 어노테이션을 쓰면, 데이터베이스에 SQL 쿼리를 보내기 전에 예외가 발생한다.
JPA의 Repository 인터페이스가 잘못된 Entity를 저장할 때, ConstraintViolationException을 발생시킨다.
(그 때문에, @Valid나 @Validated 없이도 엔티티를 자연스럽게 검증할 수 있다)
물론 값이 검증에 맞지 않아도 객체를 생성하는 것은 가능했다.
또한, Bean Validation의 트리거가 EntityManager가 Flush된 이후이므로,
원하는 타이밍에 맞지 않아 의도치 않은 오류를 맞을 수도 있다.
그러나 nullable=false 로 @Column 어노테이션에 속성을 붙이면,
null을 넣은 엔티티를 생성하면 생성이 된 뒤 Repository에 전달되고,
이 값이 DB에 넘어간 뒤에 예외가 발생해 위험한 오류를 맞을 수 있다.
이렇게 둘의 장단점을 비교해 보았을 때,
@NotNull을 써서 DB와 서버 모두의 안정성을 챙기는 것이 좋겠다고 생각했다.
참고
https://kafcamus.tistory.com/15