반응형

RestController 에서 Josn 형식으로 값을 잘 받아오던게 갑자기 안된다.

No serializer found for class org.hibernate

이런 에러가 나온다.

 

@ManyToOne에서 fetch=FetchType.LAZY 전략을 써서 

Hibernate에서 LAZY 로딩으로 인한 JSON Serialization에러가 발생한 것이라고 한다.

 

그런데 나는 fetch 설정을 한적이 없다..

심지어 @ManyToOne에서 fetch의 default 값은 EAGER 이다

 

default값

OneToMany: LAZY

ManyToOne: EAGER

ManyToMany: LAZY

OneToOne: EAGER

 

해결은

해당 Object를 JSON으로 변환하지 않는다면, @JsonIgnore 어노테이션을 nested 객체에 붙인다

@JsonIgnoreProperties({"hibernateLazyInitializer","handler"})

 

이 방법으로 해결했다..

 

다른 방법으로는 application.properties 에 spring.jackson.serialization.fail-on-empty-beans=false

이 설정을 추가 하면 된다.

 

그런데 에러를 보이지 않게만 하는 방식이라 어떤 위험이 있을지는 모르겠다..

 

반응형
반응형

 

하아...

 

Entity에 @ManyToOne 어노테이션을 이용해서 참조 관계를 만들고 데이터 저장을 테스트 하던중

 

이상하게도 자꾸 참조키(외래키)의 값이 null 이라고 에러가 뜨면서 저장이 되지 않았다...

 

처어어언천히 Entity의 설정을 살펴보니

 

@JoinColumn(... insertable=false ,updatable=false) 이런 설정값이 들어가 있었다

 

뭐지? 하고 찾아봤는데

 

insertable : 엔티티 저장시 이 필드도 같이 저장한다. false로 설정하면 데이터베이스에 저장하지 않는다. 읽기 전용일때 사용한다.
updatable : 위와 동일한 하지만 수정일때 해당 된다.

 

....

 

그래서 값이 저장되지 않았고 id가 null 이라는 메세지가 자꾸 나온 것이다!!!!

 

하... 

반응형
반응형

Entity먼저 데이터베이스에 저장하기 위해 유저가 정의한 클래스가 필요한데 그런 클래스를

Entity라고 한다. Domain이라고 생각하면 된다.

 

일반적으로 RDBMS에서 Table을 객체화 시킨 것으로 보면 된다.

그래서 Table의 이름이나 컬럼들에 대한 정보를 가진다.

/**
* Created by Itner on 2017. 7. 20..
*/

@Entity
public class Member {
@Id
@GeneratedValue(strategy= GenerationType.AUTO)
private long id;

@Column
private String name;

@Column
private int age;

public long getId() {
return id;
}

public void setId(long id) {
this.id = id;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public int getAge() {
return age;
}

public void setAge(int age) {
this.age = age;
}
}

@Id

primary key를 가지는 변수를 선언하는 것을 뜻한다. @GeneratedValue 어노테이션은 해당 Id 값을

어떻게 자동으로 생성할지 전략을 선택할 수 있다. 여기서 선택한 전략은 "AUTO"이다.

 

@Table

별도의 이름을 가진 데이터베이스 테이블과 매핑한다. 기본적으로 @Entity로 선언된 클래스의 이름은 실제

데이터베이스의 테이블 명과 일치하는 것을 매핑한다. 따라서 @Entity의 클래스명과 데이터베이스의 테이블명이

다를 경우에 @Table(name=" ")과 같은 형식을 사용해서 매핑이 가능하다.

 

@Column

@Column 선언이 꼭 필요한 것은 아니다. 하지만 @Column에서 지정한 변수명과 데이터베이스의 컬럼명을

서로 다르게 주고 싶다면 @Column(name=" ") 같은 형식으로 작성하면 된다.

그렇지 않은 경우에는 기본적으로 멤버 변수명과 일치하는 데이터베이스 컬럼을 매핑한다.

 

Repository

Entity클래스를 작성했다면 이번엔 Repository 인터페이스를 만들어야 한다.

스프링부트에서는 Entity의 기본적인 CRUD가 가능하도록 JpaRepository 인터페이스를 제공한다.

/**
* Created by Itner on 2017. 7. 20..
*/

public interface MemberRepository extends JpaRepository<Member, Long> {

}

Spring Data JPA에서 제공하는 JpaRepository 인터페이스를 상속하기만 해도 되며,

인터페이스에 따로 @Repository등의 어노테이션을 추가할 필요가 없다.

 

JpaRepository를 상속받을 때는 사용될 Entity 클래스와 ID 값이 들어가게 된다.

즉, JpaRepository<T, ID> 가 된다.

 

그렇게 JpaRepository를  단순하게 상속하는 것만으로 위의 인터페이스는 Entity 하나에 대해서

아래와 같은 기능을 제공하게 된다.

 method

 기능

 save()

 레코드 저장 (insert, update)

 findOne()

 primary key로 레코드 한건 찾기
 findAll()

 전체 레코드 불러오기. 정렬(sort), 페이징(pageable) 가능

 count()  레코드 갯수
 delete()  레코드 삭제

 

위의 기본기능을 제외한 조회 기능을 추가하고 싶으면 규칙에 맞는 메서드를 추가해야한다.

/**
* Created by Itner on 2017. 7. 20..
*/

public interface MemberRepository extends JpaRepository<Member, Long> {

Member findByName(String name);

Page<Member> findByName(String name, Pageable pageable);
}

위와 같이 Query 메소드를 추가하여 스프링에게 알릴 수 있다.

그러기위해서는 규칙에 맞는 메서드를 작성해야 하는데, 그 규칙은 다음과 같다.

method

설명 

 findBy로 시작

 쿼리를 요청하는 메서드 임을 알림

 countBy로 시작

 쿼리 결과 레코드 수를 요청하는 메서드 임을 알림

 

위의 findBy에 이어 해당 Entity 필드 이름을 입력하면 검색 쿼리를 실행한 결과를 전달한다.

SQL의 where절을 메서드 이름을 통해 전달한다고 생각하면 된다.

 

메서드의 반환형이 Entity 객체이면 하나의 결과만을 전달하고, 반환형이 List라면 쿼리에 해당하는

모든 객체를 전달한다. 

 

Query 메소드에 포함할 수 있는 키워드는 다음과 같다.

메서드 이름 키워드

 샘플

 설명

 And

 findByEmailAndUserId(String email, String userId)

 여러필드를 and 로 검색

 Or

 findByEmailOrUserId(String email, String userId)

 여러필드를 or 로 검색

 Between

 findByCreatedAtBetween(Date fromDate, Date toDate)

 필드의 두 값 사이에 있는 항목 검색

 LessThan

 findByAgeGraterThanEqual(int age)

 작은 항목 검색

 GreaterThanEqual

 findByAgeGraterThanEqual(int age)

 크거나 같은 항목 검색

 Like

 findByNameLike(String name)

 like 검색

 IsNull

 findByJobIsNull()

 null 인 항목 검색

 In

 findByJob(String … jobs)

 여러 값중에 하나인 항목 검색

 OrderBy

 findByEmailOrderByNameAsc(String email)

 검색 결과를 정렬하여 전달

 

좀 더 자세한 키워드와 쿼리를 보고 싶다면 JPA 레퍼런스를 참고하면 된다.

>> http://docs.spring.io/spring-data/jpa/docs/1.10.1.RELEASE/reference/html/#jpa.sample-app.finders.strategies

 

Pageable

위 코드 중 한가지 설명이 빠진 것이 있는데, 바로 Pageable이다.

Query 메소드의 입력변수로 위와 같이 Pageable 변수를 추가하면 Page타입을 반환형으로 사용할 수 있다.

Pageable 객체를 통해 페이징과 정렬을 위한 파라미터를 전달한다.

 

Pageable 입력 변수는 아래와 같이 Controller에서부터 전달받아야 한다.

/**
* Created by Itner on 2017. 7. 20..
*/

@RestController
@RequestMapping("/member")
public class MemberController {

@Autowired
MemberService memberService;

@RequestMapping("")
Page<Member> getMembers(Pageable pageable){
return memberService.getList(pageable)
}
}

위와 같이 작성된 Pageable에서는 다음과 같은 파라미터를 자동 수집한다.

 query parameter 명

 설명

 page

 몇번째 페이지 인지를 전달

 size

 한 페이지에 몇개의 항목을 보여줄것인지 전달

 sort

 정렬정보를 전달. 정렬정보는 필드이름,정렬방향 의 포맷으로 전달한다.

 여러 필드로 순차적으로 정렬도 가능하다.

 

예: sort=createdAt,desc&sort=userId,asc

 

아래는 위 Controller를 통해 HTTP요청으로 페이징과 정렬된 데이터를 전달받는 URI 샘플이다.

GET /users?page=1&size=10&sort=createdAt,desc&sort=userId,asc

 

이렇게 웹 페이지 개발에 필수적인 정렬과 페이지 정보를 접속 URI에서부터 Repository까지 바로 전달이 가능하다.

반응형
반응형

1. JPA(Java Persistence API)?

RDBMS 와 OOP 객체 사이의 불일치에서 오는 패러다임을 해결하기 위해

자바는 ORM(Object-Relational Mapping) 기술을 만들어 냈다.

문자 그대로 ORM 은 객체와 RDBMS 를 매핑하는 역할을 한다.

ORM 기술을 구현하기 위해 만들어져 사용되어 온 프레임워크가 Hibernate 이고,

시간이 지나면서 Hibernate 이외에도 ORM 기술을 구현하는 프레임워크(TopLink, CoCobase) 가 등장하였다.

그리고 이런 ORM 기술을 구현한 프레임워크에 대한 표준화가 이루어 졌는데,

그 결과로 만들어진 것이 JPA 인 것이다.

 

JDBC API 가 어플리케이션과 DMBS 사이에서 인터페이스 역할을 해 주기 때문에,

개발자는 사용할 DB 의 드라이버만 변경해 주면 되는 것처럼,

(DB 드라이버는 JDBC 표준에 맞추어 DB 관련 처리가 구현되어 있고, DB 드라이버는 각 DB 회사가 알아서 만들어 놓았다)

개발자는 ORM 을 기술을 사용할 때, JPA 인터페이스에 맞추어 구현되어 있는 

Hibernate, TopLink, CoCoBase 프레임워크 중 골라서 사용하면 된다.

만약, JPA 같은 표준 인터페이스가 없다면, 

ORM 기술을 사용하기 위한 Hibernate, TopLink, CoCoBase 의 필드와 메소드가 다를 것이다.

같은 기능을 가지는 메소드인데 Hibernate 에서는 냥냥고고( ), TopLink 에서는 멍멍고고( )로 정의되어 있다면,

사용하는 개발자가 ORM 프레임워크를 변경해야 할 때 난감할 것이다.

그래서 JPA API 가 이 기능은 통일해서 냥이최고( ) 로 구현하라고 강제하는 것이다(인터페이스의 중요 기능).

 

ORM 프레임워크를 사용하면 개발자가 객체를 데이터베이스에 저장할 때 SQL을 직접 작성할 필요 없이,

자바 컬렉션에 저장하는 것처럼 ORM 프레임워크에 저장하면 된다.

객체를 받은 ORM 프레임워크는 저장된 자바 객체를 분석해서 적절한 SQL을 생성하고 데이터베이스에 저장시킨다.  

 

2. 영속성(Persistence)

(1) Entity Class

엔티티 클래스는 자바 클래스에 @Entity 어노테이션을 붙여, 테이블과 매핑한다고 JPA 에게 알려주는 클래스다.

그리고 엔티티 클래스에서 만들어진 객체를 엔티티라고 한다.

 

(2) 영속성 컨텍스트(Persistence Context)

영속성 컨텍스트는 엔티티 클래스에서 만들어지는 엔티티를 영구 저장하고 관리하는 환경이다.

 

영속성 컨텍스트 와 관련한 엔티티의 4가지 상태

 ① 비영속(new/transient) - 엔티티 객체가 만들어져서 아직 저장되지 않은 상태로, 영속성 컨텍스트와 전혀 관계가 없는 상태

 ② 영속(managed) - 엔티티가 영속성 컨텍스트에 저장되어, 영속성 컨텍스트가 관리할 수 있는 상태

 ③ 준영속(detached) - 엔티티가 영속성 컨텍스트에 저장되어 있다가 분리된 상태로, 영속성 컨텍스트가 더 이상 관리하지 않는 상태

 ④ 삭제(removed) - 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제

 

영속성 컨텍스트의 특징

 ① 영속성 컨텍스트는 엔티티를 식별자 값(@Id로 테이블의 기본키와 매핑한 필드 값)으로 구분한다. 

     그렇기 때문에 영속 상태는 식별자 값이 반드시 있어야 한다.

 ② 영속성 컨텍스트에 엔티티를 저장하면 바로 데이터베이스에 저장되는 것이 아니라, 1차 캐시에 엔티티를 생성하고,

     쓰기 지연 SQL 저장소에 쿼리문을 생성해서 저장한다. 이렇게 쌓인 쿼리문은 flush( )가 실행될 때 데이터베이스에 반영된다.

 

(3) 엔티티 생성

1. 자바 어플리케이션에서 어떤 엔티티가 만들어져서 JPA에게 데이터베이스 저장을 부탁하면,

2. 만들어진 엔티티는 1차적으로 영속성 컨텍스트에 저장된다. 1차 캐시 정도라고 생각하면 된다.

   그리고, 저장한 엔티티를 데이터베이스에 저장하기 위한 쿼리문을 생성시켜 쓰기 지연 SQL 저장소에  저장한다.

   계속해서 엔티티를 넘기면 엔티티들과 쿼리문들은 차곡차곡 영속성 컨텍스트에 저장된다.

3. 그러다가 자바 어플리케이션에서 커밋 명령이 내려지면 영속 컨텍스트에는 자동으로 flush( )가 호출되고,

4. 영속성 컨텍스트의 변경내용을 데이터베이스와 동기(flush)화 한다(SQL 저장소의 쿼리를 실행시킨다).

5. 마지막으로 데이터베이스에게 commit 쿼리문을 명령한다.

 

 

(4) 엔티티 조회 

1. 자바 어플리케이션에서 JPA에게 데이터베이스 조회를 부탁하면,

   1차적으로 영속성 컨텍스트에서 엔티티를 찾는다. 

2. 있으면 자바 어플리케이션에 엔티티를 넘긴다.

3. 영속성 컨텍스트에 없는 엔티티 조회를 부탁하면

4. 쿼리문을 사용해 데이터베이스에서 찾아와 

5. 영속성 컨텍스트에 엔티티로 저장하고

6. 자바 어플리케이션에 그 엔티티를 넘긴다.

 

 

 

(5) 엔티티 변경

JPA는 엔티티를 영속성 컨텍스트에 보관할 때, 최초의 상태를 복사해서 저장해 두는데,

이것을 스냅샷이라 한다.

 

1. 자바 어플리케이션에서 커밋 명령이 들어오면, 영속 컨텍스트에는 자동으로 flush( )가 호출되고,

2. 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다.

3. 변경된 엔티티가 있으면 데이터베이스에 변경사항을 저장하기 위해 쿼리를 생성하고,

4. 영속성 컨텍스트의 변경내용을 데이터베이스와 동기(flush)화 한다(SQL 저장소의 쿼리를 실행시킨다).

5. 마지막으로 데이터베이스에게 commit 쿼리문을 명령한다.

이렇게 엔티티의 변경사항을 데이터베이스에 자동으로 반영하는 기능을 변경감지(Dirty Checking)이라 한다.

 

 

(6) 엔티티 삭제

앞의 과정과 마찬가지로, 자바 어플리케이션에서 엔티티 삭제 명령이 들어오면,

엔티티를 찾고 쓰기 지연 SQL 저장소에 delete 쿼리를 생성한다.

그리고 자바 어플리케이션에서 커밋 명령이 들어오면, 자동으로 flush( )가 호출되고,

영속성 컨텍스트의 변경내용을 데이터베이스와 동기(flush)화 한다(SQL 저장소의 쿼리를 실행시킨다).

마지막으로 데이터베이스에게 commit 쿼리문을 명령한다. 

 

3. JPA 메소드

(1) flush( )

영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.

 

실행되었을 때 일어나는 일

  ① 변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샵과 비교해서 수정된 엔티티를 찾고,

      수정된 엔티티를 데이터베이스에 반영하기 위해 수정 쿼리를 생성하여 지연 SQL 저장소에 등록

  ② 쓰기 지연 SQL 저장소의 쿼리를 데이터 베이스에 전송(등록, 수정, 삭제 쿼리)

  

보통 직접 사용하지 않고, 자바 어플리케이션에서 커밋 명령이 들어왔을 때, 자동으로 실행된다.

 

(2) detach( )

특정 엔티티를 준영속 상태로 만든다. 

준영속 상태가 된 엔티티는 더이상 영속 컨텍스트의 관리를 받지 않으며,

영속 컨텍스트가 지원하는 어떤 기능도 동작하지 않게 된다.

영속 상태가 영속성 컨텍스트로에게 관리(managed)되는 상태라고 하면,

준영속 상태는 영속성 컨텍스트로부터 분리(detached)된 상태이다.

 

(3) clear( )

영속성 컨텍스트를 초기화 한다.

영속성 컨텍스트의 모든 엔티티를 준영속 상태로 만든다.

 

(4) close( )

영속성 컨텍스트를 종료한다.

영속성 컨텍스트가 관리하던 영속 상태의 엔티티가 모둔 준영속 상태가 된다.

 

영속 상태의 엔티티는 주로 영속성 컨텍스트가 종료되면서 준영속 상태가 된다.

개발자가 직접 준영속 상태로 만드는 일은 거의 없다.

 

(5) merge( )

준영속 상태의 엔티티의 특징

 ① 거의 비영속 상태에 가깝다. 영속성 컨텍스트가 관리하지 않으므로 영속성 컨텍스트가 제공하는 어떠한 기능도 동작하지 않는다.

 ② 식별자 값을 가지고 있다. 비영속 상태의 엔티티는 식별자(엔티티를 구분하기 위한 유일한 값, ID)를 가지지 않고 있을 수도 있지만,

     준영속 상태는 이미 한 번 영속 상태였기 때문에, 식별자 값을 가지고 있다.

 

merge( )는 준영속 상태의 엔티티를 이용해서 새로운 영속 상태의 엔티티를 반환한다.

 

실행되었을 때 일어나는 일

 ① 파라미터로 넘어온 준영속 엔티티의 식별자 값으로 1차 캐시에서 엔티티를 조회

     (1차 캐시에 엔티티가 없으면 데이터베이스에서 엔티티를 조회하고 1차 캐시에 저장)

 ② 조회한 영속 엔티티에 준영속 엔티티의 값을 채워 넣는다.

 ③ 생성된 새로운 영속 엔티티를 반환한다.

새롭게 생성된 영속 상태의 엔티티를 가지고 이제 영속성 컨텍스트가 지원하는 기능을 사용할 수 있다.

 

준영속 상태의 엔티티를 영속 상태로 변경하는 것이 아니라, 새로운 영속 상태의 엔티티를 만들어서,

준영속 상태의 엔티티 값을 영속 상태의 엔티티에 채워 넣어서 반환하는 점에 주의해야 한다.

그리고, 준영속 뿐만 아니라, 비영속 상태의 엔티티도 병합하여 새로운 영속 상태의 엔티티를 만들어 반환한다.

 

자세한 내용은 위의 엔티티 변경 참조.

 

(6) find( )

식별자 값을 가지고 엔티티를 찾아서 반환한다.

자세한 내용은 위의 엔티티 조회 참조

 

(7) persist( )

자바 어플리케이션에서 생성된 엔티티를 영속성 컨텍스트와 데이터베이스에 저장한다.

자세한 내용은 위의 엔티티 생성 참조

 

(8) remove( )

식별자 값을 가지고 엔티티를 찾아서 삭제한다.

자세한 내용은 위의 엔티티 삭제 참조



출처: https://tinkerbellbass.tistory.com/24 [Welcome to NeverLand]

반응형

'Spring Framework' 카테고리의 다른 글

[Spring JPA 에러] QuerySyntaxException is not mapped  (0) 2019.07.23
JPA 기본 사용법  (0) 2019.06.24
(STS) Spring Framework-Lombok 설치  (0) 2019.06.23
Spring MVC 라이프 사이클  (0) 2019.06.20

+ Recent posts