스프링 Data 에서 제공하는 @CreatedDate, @LastModifedDate 애너테이션을 이용해서 작성일자, 수정일자를 도메인객체가 생성되고, 수정될 때 관리될 수 있도록 한다.
Spring Data를 쓰기 전에는 DB컬럼에 Date 타입의 등록일 컬럼을 추가하고 DEFAULT 값으로 SYSDATE 를 줘서 DB에 Insert 되는 시간에 등록일자 컬럼이 채워지는 방식을 사용했었고, Update 쿼리가 실행될때 수정일자 컬럼에 SYSDATE를 직접 Update 해주는 방식을 자주 썼다.
그 뿐만아니라, 등록일자와 더불어 등록한 사용자(ex: registerUser)를 식별하는 식별키(ex: userId, username ...) 를 Insert 쿼리가 실행될때 등록해주고, 수정한 사용자(ex: modifedUser)를 Update 쿼리에 설정하는 방식은 차후에 있을지도 모를 일에 대비해서 늘 반복해서 작업했다.
스프링 Data 에서 제공하는 JPA Audit 기능은 이런 코드의 반복을 줄여준다.
사용자 같은 경우 객체로 넘기면 객체의 식별자가 담긴다. 등록시간은 날짜형 타입이다.
Blog 클래스의 User 객체는 @CreatedBy 애너테이션으로 선언되서 등록한 사용자를 나타내는 컬럼에 값을 입력할것이다. createdDate 필드는 도메인객체가 영속성 저장소에 반영되는 시간을 나타낸다.
Fridge, Food 클래스에 등록일, 수정일만 먼저 적용한다.
두 클래스에 createdDate, lastModifedDate 멤버변수를 선언한다.
class 선언부에 @EntityListeners(AuditingEntityListener.class) 는 JPA Auditing 기능을 이용하기 위해 선언하는 애너테이션이다. 멤버 변수 LocalDateTime 타입의 createdDate, lastModifedDate을 추가한다. 마지막으로 Application 클래스에 @EnableJpaAuditing 애너테이션을 선언한다.
Spring Data Rest 에서는 @LastModifedDate 애너테이션을 선언한 Date컬럼 값을 응답헤더에 Last-Modifed 헤더네임으로 보내주고, Client에서 Http 헤더에 If-Modifed-Since 조건부 헤더 값으로 최종수정일 값을 다시 보내주면서 Update할 내용을 요청바디에 실어서 보낸다. 서버는 헤더에서 넘어온 시간을 보고 리퍼지토리에서 데이터를 들고와서 요청바디에서 보내온 데이터와 비교해서 변경할 부분이 있으면 Update한다. 만약 업데이트할 부분이 없다면 중복된 요청이므로 응답 HttpStatus 코드 304 Not Modifed를 보내줘서 반복적인 수정을 막아준다.
Spring Data Rest에서 헤더를 이용한 부분은 ETag 를 이용한 PUT, PATCH, DELETE 에서의 Lock이 있다. @LastModifedDate 애너테이션처럼 @Version 애너테이션은 Entity에 @Version Long version 이라는 멤버변수를 선언해주면 DB에서 데이터가 갱신될때마다 Version 값이 계속 증가한다. 서로 다른 두 클라이언트에서 동일한 데이터를 보고있다고 가정한다. A 클라이언트와 B클라이언트는 동일한 ETag(Version 1)을 가진다. A가 먼저 Put을 해서 서버는 Version이 증가하지만, B클라이언트의 Version은 여전히 1이다. B클라이언트가 Put을 날리면 서버의 Version과 같지 않으므로 응답상태코드 412 Precondition Failed를 응답한다.
헤더를 이용한 방식은 클라이언트의 반복적인 요청에 대해 서버 자원을 아낄 수 있다.
지금 당장은 Spring Data Rest에서 사용되는 방향으로 LastModifiedDate 컬럼을 활용하지는 않지만, 차후에 @Version과 @LastModifedDate 애너테이션을 헤더를 이용하는 방안까지 설계할 예정이다.
생성일, 최종수정일은 아직 UI에서는 쓸일이 없지만 내부적으로 생성일자와 수정일자가 관리되는것에 의미가 있다.
이전글: 냉장고 가계부 프로젝트 26
다음글: 냉장고 가계부 프로젝트 27
Spring Data를 쓰기 전에는 DB컬럼에 Date 타입의 등록일 컬럼을 추가하고 DEFAULT 값으로 SYSDATE 를 줘서 DB에 Insert 되는 시간에 등록일자 컬럼이 채워지는 방식을 사용했었고, Update 쿼리가 실행될때 수정일자 컬럼에 SYSDATE를 직접 Update 해주는 방식을 자주 썼다.
그 뿐만아니라, 등록일자와 더불어 등록한 사용자(ex: registerUser)를 식별하는 식별키(ex: userId, username ...) 를 Insert 쿼리가 실행될때 등록해주고, 수정한 사용자(ex: modifedUser)를 Update 쿼리에 설정하는 방식은 차후에 있을지도 모를 일에 대비해서 늘 반복해서 작업했다.
스프링 Data 에서 제공하는 JPA Audit 기능은 이런 코드의 반복을 줄여준다.
사용자 같은 경우 객체로 넘기면 객체의 식별자가 담긴다. 등록시간은 날짜형 타입이다.
public class Blog {
@CreatedBy
private User user;
@CreatedDate
private LocalDateTime creadtedDate;
}
Blog 클래스의 User 객체는 @CreatedBy 애너테이션으로 선언되서 등록한 사용자를 나타내는 컬럼에 값을 입력할것이다. createdDate 필드는 도메인객체가 영속성 저장소에 반영되는 시간을 나타낸다.
Fridge, Food 클래스에 등록일, 수정일만 먼저 적용한다.
두 클래스에 createdDate, lastModifedDate 멤버변수를 선언한다.
@Data
@NoArgsConstructor
@Entity
@EntityListeners(AuditingEntityListener.class)
public class Fridge {
...
private @CreatedDate LocalDateTime createdDate;
private @LastModifiedDate LocalDateTime lastModifiedDate;
...
}
class 선언부에 @EntityListeners(AuditingEntityListener.class) 는 JPA Auditing 기능을 이용하기 위해 선언하는 애너테이션이다. 멤버 변수 LocalDateTime 타입의 createdDate, lastModifedDate을 추가한다. 마지막으로 Application 클래스에 @EnableJpaAuditing 애너테이션을 선언한다.
@SpringBootApplication
@EnableJpaAuditing
public class FridgeApplication {
public static void main(String[] args) {
SpringApplication.run(FridgeApplication.class, args);
}
}
Spring Data Rest 에서는 @LastModifedDate 애너테이션을 선언한 Date컬럼 값을 응답헤더에 Last-Modifed 헤더네임으로 보내주고, Client에서 Http 헤더에 If-Modifed-Since 조건부 헤더 값으로 최종수정일 값을 다시 보내주면서 Update할 내용을 요청바디에 실어서 보낸다. 서버는 헤더에서 넘어온 시간을 보고 리퍼지토리에서 데이터를 들고와서 요청바디에서 보내온 데이터와 비교해서 변경할 부분이 있으면 Update한다. 만약 업데이트할 부분이 없다면 중복된 요청이므로 응답 HttpStatus 코드 304 Not Modifed를 보내줘서 반복적인 수정을 막아준다.
Spring Data Rest에서 헤더를 이용한 부분은 ETag 를 이용한 PUT, PATCH, DELETE 에서의 Lock이 있다. @LastModifedDate 애너테이션처럼 @Version 애너테이션은 Entity에 @Version Long version 이라는 멤버변수를 선언해주면 DB에서 데이터가 갱신될때마다 Version 값이 계속 증가한다. 서로 다른 두 클라이언트에서 동일한 데이터를 보고있다고 가정한다. A 클라이언트와 B클라이언트는 동일한 ETag(Version 1)을 가진다. A가 먼저 Put을 해서 서버는 Version이 증가하지만, B클라이언트의 Version은 여전히 1이다. B클라이언트가 Put을 날리면 서버의 Version과 같지 않으므로 응답상태코드 412 Precondition Failed를 응답한다.
헤더를 이용한 방식은 클라이언트의 반복적인 요청에 대해 서버 자원을 아낄 수 있다.
지금 당장은 Spring Data Rest에서 사용되는 방향으로 LastModifiedDate 컬럼을 활용하지는 않지만, 차후에 @Version과 @LastModifedDate 애너테이션을 헤더를 이용하는 방안까지 설계할 예정이다.
생성일, 최종수정일은 아직 UI에서는 쓸일이 없지만 내부적으로 생성일자와 수정일자가 관리되는것에 의미가 있다.
이전글: 냉장고 가계부 프로젝트 26
다음글: 냉장고 가계부 프로젝트 27