1. id는 Long 타입으로 하자 🫢
Table 'scheduleplus.schedule' doesn't exist
GenerationTarget encountered exception accepting command : Error executing DDL "
alter table schedule
add constraint FKa50n59y1j4a6qwa42p8jiguds
foreign key (user_id)
references user (id)" via JDBC [Table 'scheduleplus.schedule' doesn't exist]
- 엔티티 클래스 id를
String으로 선언했더니 그랬었다. - 테이블 생성하려고 하는데 id가
Long이 아니니 테이블 생성이 안됐다.
@GeneratedValue(strategy = GenerationType.IDENTITY)는
MySQL의 auto-increment 기능을 사용하는데, 숫자 타입에서만 동작한다.
2. 컬럼 순서가 "불편해" 🤨
나는 사진처럼 컬럼 순서를 정렬해서 사용하고 싶은데
순서를 내가 지정할 수 없으셈ㅋ
💡 spring.jpa.hibernate.ddl-auto=create 사용 시
- 하이버네이트가 DDL을 자동 생성할 때
컬럼이 알파벳 순서(a~z)로 삽입됨 - 따라서 선언한 순서대로 생성되지 않음...
방법은 있긴 한데...
- 적용하기 복잡하고, 다들 잘 안쓰는 것 같다.
- 실제 운영환경에선 쓰지 않는 설정이고,
테스트 환경에서만 사용해서 그런 것 같다.
📢 김영한님은
컬럼 순서를 고정시킬 수 있는 보편적인 방법이 없으며,
하이버네이트가 자동으로 생성해주는 DDL은 신뢰성이 떨어지기 때문에
실제 운영 환경에서는 JPA로 생성된 테이블의 DDL을 참고하여
개발자가 직접 스키마를 정의하고 관리하는 것을 권장한다고 한다.
✅ 그래서 나는
spring.jpa.hibernate.ddl-auto=none으로 설정하고- 루트 디렉토리에
schema.sql로 테이블 생성 SQL을 직접 작성했다~
3. DTO는 final로 설정하는 것이 맞을까? 🧐
내용이 길어져서 하나의 글로 정리해보았다.
✅ 결론은
-
QueryString, FormData를 받기위한 DTO는 final로 설정하는 것이 국룰이다.
→ 불변성 보장, 신뢰할 수 있는 객체 설계 -
기본 생성자의 경우, 최대한 접근제어자를 통해 관리하자.
→ 무분별한 객체 생성 방지 -
생성자가 두개 이상일 경우
→@JsonCreator로 어떤 생성자를 사용할 것인지 지정해주어야 한다.
4. Entity 기본 생성자는 왜 필수일까?
이 내용도 길어져서 하나의 글로 정리해보았다. ㅎㅎ
✅ JPA가 리플렉션 API를 사용해서 그렇다.
❓ 나는 안써도 되던뎅?
하이버네이트가 도와준것임ㅋ
따라서 JPA에서 가이드한 것처럼 기본 생성자를 제발 넣자!
❓ 왜 기본 생성자는 private을 붙이면 안되나용?
- JPA가 엔티티에 지연로딩(lazy)으로 접근할 때,
하이버네이트가 프록시(가짜) 객체를 생성해서 사용하기 때문이라고 한다.- 프록시 객체는 실제 엔티티 객체를 상속받은 객체이기 때문에
상속하기 위해public또는protected이어야 한다.
@RequiredArgsConstructor, @AllArgsConstructor 차이점
@AllArgsConstructor를 무분별하게 사용하는 것 같다는 피드백이 있었다.
두개의 차이점을 알고 제대로 사용해보자..
공통점
- 생성자를 자동으로 생성해주는 기능이다.
차이점
@RequiredArgsConstructor의 경우
- final 필드와 @NonNull이 붙은 필드만 생성자에 포함된다.
- 불변 객체를 만들 때 유용하다. ex. DTO
@AllArgsConstructor의 경우
- 모든 필드를 포함하는 생성자를 자동으로 생성한다.
출처
- DTO는 final로 설정하는 것이 맞을까?
- 엔티티클래스에 기본생성자는 왜 필수일까?
wannabe---ing