가끔 올리는 (비)개발 이야기

JPA - 6장 - 다양한 연관관계 매핑

Tue, 27 Dec 2016 00:00:00 +0000

※ 이 문서는 개인적인 필요에 의해 JPA 프로그래밍 책을 요약/추가 한 내용입니다.

다대일

다대일 단방향 [N:1]

---------  *           1  ----------
Member    --------------> Team
---------                 ----------
id                        id
Team team                 name
username
---------                 ----------

Member에서는 @MenyToOne 으로 Team을 참조 할 수 있도록 해주고 Team에서는 별도의 설정을 하지 않는다.

Member

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;

  @ManyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;
}

Team

@Entity
public class Team {
  @Id @GeneratedValue
  @Column(name = "TEAM_ID")
  private Long id;

  private String name;
}

다대일 양방향 [N:1, 1:N]

---------           team  ----------
Member    --------------> Team
---------  members     1  ----------
id        <-------------- id
Team team  *              List members
username                  name
---------                 ----------

Member에서는 @MenyToOne 으로 Team을 참조 할 수 있도록 해주고 Team에서는 @OneToMany 와 함께 mappedBy값을 설정 해서 연관관계의 주인이 Member테이블임을 알려준다.

항상 1:N, N:1 관계에서는 항상 N쪽에 외래키가 있다. 여기에서는 N쪽인 Member 테이블이 외래키를 가지게 된다. 그러므로 Member.team이 연관관계의 주인이 된다.

Member

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;

  @ManyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;

  public void setTeam(Team team){
    this.team = team;

    if(!team.getMembers().contains(this)){
      team.getMembers.().add(this);
    }
  }
}

Team

@Entity
public class Team {
  @Id @GeneratedValue
  @Column(name = "TEAM_ID")
  private Long id;

  @OneToMany(meppedBy = "team")
  private List<Member> members

  private String name;

  public void addMember(Member member){
    this.members.add(member);
    if(member.getTeam() != this){
      member.setTeam(this);
    }
  }
}

일대다

일대다 단방향 [N:1]

---------  1           *  ----------
Team      --------------> Member
---------        members  ----------
id                        id
name                      username
List members
---------                 ----------

보통은 자신이 매핑한 테이블의 외래키를 가지는데 반해 여기서는 Member 테이블에 외래키가 있다. 일대다 관계에서는 꼭 JoinColumn을 선언 해줘야 한다. 안그러면 조인 테이블을 중간에 두는 방식으로 설정 된다.

일대다의 단점은 매핑한 객체가 관리하는 외래 키가 다른 테이블에 있으므로 Insert SQL한번으로 조작이 끝나는것이 아닌 연관 테이블의 Update도 해줘야하는 문제가 있다.

그러므로, 일대다 보다는 다대일 단방향 매핑을 사용하자~~~!!!

Team

@Entity
public class Team {
  @Id @GeneratedValue
  @Column(name = "TEAM_ID")
  private Long id;

  @OneToMany
  @JoinColumn(name = "TEAM_ID") // Member 테이블의 TEAM_ID 를 나타냄
  private List<Member> members;

  private String name;
}

Member

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;
}

일대다 단방향 [N:1]

일대다 양방향 매핑은 존재 하지 않는다. 대시 다대일 매핑을 사용해야 한다. 다시 말해 양방향 매핑에서는 @OneToMany는 연관관계의 주인이 될 수 없다는 것이다.

일대일

양쪽이 서로 하나의 관계만을 가진다. 즉, 일대일 관계는 그 반대도 일대일 관계다.

주 테이블에 외래 키

JPA에서는 주 테이블에 외래 키가 있는것이 좀더 편리하게 매핑할 수 있게된다.

단방향

Member 와 Locker의 관계로 알아보자. 아래 모습은 다대일(N:1)단방향 모습과 매우 흡사하다.

------------   1           1  ----------
Member        --------------> Locker
------------                  ----------
id                            id
Locker locker                 name
username                  
------------                  ----------

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;

  @OneToOne
  @JoinColumn(name = "LOCKER_ID")
  private Locker locker;
}

@Entity
public class Locker {
  @Id @GeneratedValue
  @Column(name = "LOCKER_ID")
  private Long id;

  private String name;
}

양방향

양방향의 주인이 정해 졌다. Member 테이블의 왜래키를 가지고 있으며 Member.locker가 연관관계의 주인이다. Locker는 mappedBy를 이용해서 연관관계의 주인을 선언한다.

------------           locker ----------
Member        --------------> Locker
------------               1  ----------
id             1              id
Locker locker <- - - - - - -- name
username       member         Member member
------------                  ----------

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;

  @OneToOne
  @JoinColumn(name = "LOCKER_ID")
  private Locker locker;
}

@Entity
public class Locker {
  @Id @GeneratedValue
  @Column(name = "LOCKER_ID")
  private Long id;

  private String name;

  @OneToOne(mappedBy = "locker")
  private Member member;
}

대상 테이블에 외래 키

JPA에서는 주 테이블에 외래 키가 있는것이 좀더 편리하게 매핑할 수 있게된다.

단방향

이는 JPA에서 지원 하지 않는다.

양방향

대상테이블인 Locker에서 외래키를 관리하는 모습이다.

------------           locker ----------
Member        - - - - - - - > Locker
------------               1  ----------
id             1              id
Locker locker <-------------- name
username       member         Member member
------------                  ----------

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;

  @OneToOne(mappedBy = "member")
  private Locker locker;
}

@Entity
public class Locker {
  @Id @GeneratedValue
  @Column(name = "LOCKER_ID")
  private Long id;

  private String name;

  @OneToOne
  @JoinColumn(name = "MEMBER_ID")
  private Member member;
}

다대다

다대다는 한쪽에 외래키를 두고 2개의 테이블로 관계를 표현 할 수가 없어서 중간에 연결테이블을 추가 하게 된다.

하지만 객체의 관계는 2개의 객체로 표현이 가능하다.

다대다 관계인 “Member”와 “Product”로 살펴보자.

단방향

Member에서 Product를 @ManyToMany로 연결한다. 중요한 점은 @JoinTable을 이용해서 연결 테이블을 설정해 주는 것이다. MEMBER_PRODUCT 테이블은 다대다 관계를 “일대다, 다대일” 관계로 풀어내기 위한 연결 테이블이다.

@Entity
public class Member {
  @Id @GeneratedValue
  @Column(name = "MEMBER_ID")
  private Long id;

  private String username;

  @ManyToMany
  @JoinTable(name = MEMBER_PRODUCT,
            joinColumns = @JoinColumn(name = "MEMBER_ID"),
            inverseJoinColumns = @JoinColumn(name = "PRODUCT_ID")
  private List<Product> products = new ArrayList<Product>();
}

@Entity
public class Product {
  @Id @GeneratedValue
  @Column(name = "PRODUCT_ID")
  private Long id;

  private String name;
}

사용 예제

public void save(){
  Product productA = new Product();
  productA.setId("ProductA");
  productA.setName("상품A");
  em.persist(productA);

  Member member1 = new Member();
  member1.setId("member1");
  member1.setUsername("회원1");
  member1.getProducts().add(ProductA); // 연관관계 설정
  em.persist(member1);
}

public void find(){
  Member member = em.find(Member.class, "member1");
  List<Product> products = member.getProducts();
  for(Product product : products){
    System.out.println("product.name = " + product.getName());
  }
}

단방향

단방향과 마찬가지로 양방향은 반대쪽도 @ManyToMany를 사용한다. 그리고 양방향중 한곳에 mappedBy를 설정해서 연관관계 주인을 지정해 준다. mappedBy가 없는 쪽이 연관관계의 주인이다.

@Entity
public class Product {
    @Id
    private String id;

    @ManyToMany(mappedBy = "products")
    private List<Member> members;

    ...
}

JPA - 5장 - 연관관계 매핑 기초

Mon, 05 Dec 2016 00:00:00 +0000

※ 이 문서는 개인적인 필요에 의해 JPA 프로그래밍 책을 요약/추가 한 내용입니다.

단방향 연관관계

연관관계중에서는 다대일(N:1)을 가정 먼저 이해 하고 넘어가야 한다. 회원과 팀의 관계가 그에 해당 한다.

회원과 팀이 있다. 회원은 하나의 팀에만 속할 수 있다.

---------           0..1  ----------
Member    --------------> Team
---------                 ----------
id                        id
Team team                 name
username
---------                 ----------

객체 연관관계

Member 객체는 Member.team 필드로 팀객체와 연관 관계를 맺고 있고 이는 단방향 관계이다. 즉 Member는 team 필드로 팀을 알수 있지만 Team은 Member를 알아 낼 수 없다.

테이블 연관관계

반면 테이블은 외래 키를 이용해서 양방향으로 조회 할 수 있다. 즉, 외래키를 이용해서 서로 JOIN해주면 양방향의 관계를 알아 낼 수 있다.

객체 관계 매핑

@Entity
public class Member {
  @Id
  @Column(name = "MEMBER_ID")
  private String id;

  private String username;

  @ManyToOne
  @JoinColumn(name = "TEAM_ID")
  private Team team;

  // Getter, Setter...
}

@Entity
public class Team {
  @Id
  @Column(name = "TEAM_ID")
  private String id;

  private String name;

  // Getter, Setter...
}

@ManyToOne

말그 대로 N:1의 관계를 라는 매핑 정보 이다.

속성

optional
- 기본은 true인데 false로 설정하면 연관된 Entity가 꼭 있어야 한다.
fetch
- 8장에서…
- FetchType.EAGER
- FetchType.LAZY
cascade
- 영속성 전이 기능을 사용
targetEntity
- 연관된 엔티티의 타입 정보를 설정

    @OneToMany
    private List<Member> members  // 제네릭으로 타입정보를 알수 있다.

    @OneToMany(targetEntity=Member.class)
    private List member // 제네릭이 없으면 타입 정보를 알수 없다.

@JoinColumn(name=”TEAM_ID”)

JoinColumn 은 외래키를 매핑할 때 사용한다.

속성

name
- 매핑할 외래 키 이름
referencedColumnName
- 외래 키가 참조하는 대상 테이블의 컬럼명
foreignKey(DDL)
- 외래키 제약조건을 직접 설정하기위한 속성이다.
unique
nullable
insertable
updatable
columnDefinition
table
- @Column속성과 같다.

연관관계 사용

저장

JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다.

Team team1 = new Team("team1", "팀1");
em.persist(team1);

Member member1 = new Member("member1", "회원1");
member1.setTeam(team1);
em.persist(member1);

Member member2 = new Member("member2", "회원2");
member2.setTeam(team1);
em.persist(member2);

조회

연관관계가 있는 엔티티를 조회 하는 방법은 “객체 그래프 탐색” 방법과 “객체지향 쿼리 사용” 이 있다.

객체 그래프 탐색

Member member = em.find(Member.class, "member1");
Team team = member.getTeam();   // <---- 이것이 객체 그래프 탐색이다.

객체지향 쿼리 사용

객체지향 쿼리인 JPQL을 이용한 방법이다.

String jpql = "select m from Member m join m.team t where t.name = :teamName";

List<Member> resultList = em.createQuery(jpql, Member.class)
                          .setParmeter("teamName", "팀1")
                          .getResultList();

수정

em.update()와 같은 함수는 없다. 단순히 아래와 같이 처리하면 된다.

Team team2 = new Team("team2", "팀2");
em.persist(team2);

Member member = em.fine(Member.class, "member1");
member.setTeam(team2);

연관 관계 제거

아래와 같이 null로 처리해 주면 관계는 삭제 된다.

Member member = em.fine(Member.class, "member1");
member.setTeam(null);

연관된 엔티티 삭제

연관된 엔티티를 삭제 하려면 해당 엔티티를 사용하는 모은 엔티티의 연관 관계를 제거 해줘야 한다.

member1.setTeam(null);
member2.setTeam(null);
em.remove(team);

양방향 연관관계

단방향에서는 “회원” –> “팀” 으로만 확인이 가능했다면 양방향에서는 “팀” –> “회원” 으로도 확인이 가능해야 한다. RDB의 Table에서의 관계는 양방향과 단방향이 모두 동일하다.(FK로 서로 교차 검색이 가능하다)

@Entity
public class Team {
  @Id
  @Column(name = "TEAM_ID")
  private String id;

  private String name;

  // 추가
  @OneToMany(mappedBy = "team")
  private List<Member> members = new ArrayList<Member>();

  // Getter, Setter...
}

mappedBy는 양방향 매핑을 할때 반대쪽에 매핑할 필드의 이름이다.

연관관계의 주인

mappedBy는 왜? 필요할까??

객체에서 양방향 관계라는 것은 없다. -> 2개의 단방향 관계가 있는 것이다.
mappedBy는 연관관계의 주인을 정해주는 작업이다.
연관관계의 주인은 외래키가 존재하는 엔티티가 된다.
즉, 연관관계 주인 만이 연관관계를 갱신할 수 있고, 반대편(inverse, non-owning side)는 읽기만 가능하다.

양방향 연관관계 저장 및 주의할 점

예제 에서는 Member.team 연관관계의 주인이므로 아래 코드의 내용에 주의 해줘야한다.

// 정상적인 연관관계의 설정은 Member 에서 이루어져야 한다.
Team team1 = new Team("team1", "팀1");
em.persist(team1);

Member member2 = new Member("member2", "회원2");
member.setTeam(team1);
em.persist(member2);

// Team에서 연관관계를 업데이트 하려고 시도하는것은 무시된다.
Member member2 = new Member("member2", "회원2");
em.persist(member2);

Team team1 = new Team("team1", "팀1");
team1.getMembers().add(member2);
em.persist(team1);

하지만 순수 객체로 따져 보면 위 예제의 정상과 비정상 예제의 내용이 모두 실행되어야 정상적으로 동작하게 된다. 그래서 Member의 setTeam을 아래와 같이 수정해 주면 순수 객체에서도 정상동작 하게 된다.

public void setTeam(Team team){
  // 기존팀 관계 제거
  //   -> 영속성 컨텍스트가 새로 시작되면 문제가 없지만 영속성 컨텍스트를 계속 사용중이라면
  //      문제가 발생 할 수 있다.
  if (this.team != null){
      this.team.getMembers().remove(this);
  }
  this.team = team;
  team.getMembers().add(this);
}

JPA - 4장 - 엔티티 매핑

Thu, 01 Dec 2016 00:00:00 +0000

※ 이 문서는 개인적인 필요에 의해 JPA 프로그래밍 책을 요약/추가 한 내용입니다.

매핑 애노테이션 을 크게 4가지로 분류하면

객체와 테이블 매핑 : @Entity, @Table
기본 키 매핑 : @Id
필드와 컬럼 매핑 : @column
연관관계 매핑 : @ManyToOne, @JoinColumn

@Entity

클래스에 @Entity 를 붙여주면 JPA가 Entity로서 관리 한다는 것을 의미한다.

속성

name
- 다른 Entity와 충돌이 우려될 경우 이름을 바꿔준다. 기본적으로는 Class명을 따른다.

주의사항

기본 생성자 필수
final, enum, interface, inner 클래스 사용 못함
저장 필드에 final 사용 못함

@Table

Entity와 매핑할 DB Table을 지정 한다.

속성

name
- 매핑할 table 이름, 기본은 Entity 이름을 사용한다.
catalog
- catalog 기능이 있는 DB에서 catalog를 매핑
schema
- schema 기능이 있는 DB에서 schema를 매핑
uniqueConstraints
- DDL 생성 시에 유니크 제약조건을 만든다.

데이터베이스 스키마 자동 생성

자동으로 스키마를 생성하는 기능은 아래 값을 설정 함으로써 가능하다.

<property name="hibernate.hbm2ddl.auto" value="create"/>

value

create
- 기존 Table Drop + 생성
create-drop
- create후 종료시 drop까지 실행
update
- 변경된 내용만 수정한다. 이건 JPA스팩에는 없고 hibernate에만 있는 설정 이다.
validate
- 기존 DB Table정보와 비교해서 차이가 있다면 경고하고 애플리케이션을 실행 하지 않는다. 이건 JPA스팩에는 없고 hibernate에만 있는 설정 이다.
none
- 설정이 없거나 유효하지 않은 값을 설정하면 기능을 사용하지 않게된다.

기본 키 매핑

primary key를 설정하는 것을 말한다.

직접할당

em.persist()를 호출하기전에 사용자가 직접 ID를 설정하는 것을 말한다.

  Board board = new Board();
  board.setId("board1");
  em.persist(board);

자동생성

IDENTITY
- 기본키의 생성을 DB에 위임하는것을 말한다. MySQL의 AUTO_INCREMENT와 같은것을 말한다.
- @GeneratedValue(strategy = GenerationType.IDENTITY) 로 설정 가능
SEQUENCE
- 유일한 값을 순서대로 생성하는 특별한 데이터베이스 오브젝트를 이용하는 방법을 말한다.
- @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = “BOARD_SEQ_GENERATOR”) 로 설정 가능

    @Entity
    @SequenceGenerator(
      name = "BOARD_SEQ_GENERATOR",
      sequenceName = "BOARD_SEQ", // 실제 DB의 Sequence Name
      initialValue = 1, allocationSize = 1 )
    public class Board {
    ...
      @Id
      @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "BOARD_SEQ_GENERATOR")
      private Long id;
    ...  
    }

TABEL
- 키 생성 전용 Table을 만들어서 이를 SEQUENCE 처럼 사용하는 것을 말한다.

    @Entity
    @TableGenerator(
      name = "BOARD_SEQ_GENERATOR",
      table = "MY_SEQUENCE", // 실제 DB의 Table name
      pkColumnValue = "BOARD_SEQ", allocationSize = 1 )
    public class Board {
    ...
      @Id
      @GeneratedValue(strategy = GenerationType.TABLE, generator = "BOARD_SEQ_GENERATOR")
      private Long id;
    ...  
    }

AUTO
- DB종류에 따라 JPA가 알맞은 것을 선태 하는것을 의미한다. Oracle의 경우 SEQUENCE, MySQL의 경우 IDENTITY를 선택하게 된다.
- 또하나의 장점은 DB종류가 바뀌어도 소스를 수정하지 않아도 된다는 것이다.
- @GeneratedValue(strategy = GenerationType.AUTO) 로 설정 가능

필드와 컬럼 매핑 : 레퍼런스

필드와 컬럼 매핑에 사용되는 어노테이션으로는 @Column, @Enumerated, @Temporal, @Lob, @Transient, @Access 가 있다.

@Column

객체 필드를 테이블 컬럼과 매핑해주는 가장 대표적인 어노테이션이다. name, nullable이 가장 많이 사용되고 나머지는 많이 사용되지는 않는다.

속성

name
- 매핑할 table 컬럼 이름, 기본은 객체의 필드 이름을 사용한다.
insertable
- 거의 사용안됨, 엔티티 저장시 이 필드도 저장하라는 의미로 기본은 true이다 단 false로 하면 Readonly일때 사용가능 하다.
updatable
- 거의 사용안됨, 엔티티 수정시 이 필드도 수정하라는 의미로 기본은 true이다 단 false로 하면 Readonly일때 사용가능 하다.
table
- 거의 사용안됨, 하나의 엔티티를 두 개 이상의 테이블에 매핑할때 사용
nullable
- false로 설정하면 DDL생성시에 “NOT NULL” 제약조건을 추가해 준다.
unique
- @Table 의 uniqueConstraints와 같지만 한컬럼에 대해서 적용할때는 간단하게 이걸 이용가능, 단 여러 컬럼을 사용할때는 @Table의 uniqueConstraints를 사용해야 한다.
columnDefinition
- 사용자가 직접 컬럼의 정보를 입력해준다.
length
- 문자 길이에 대한 제약조건을 준다. String 타입에만 적용되며 기본값은 255이다.
precision, scale
- BigDecimal 타입에서 사용된다. precision은 소수점을 포함한 전체 지릿수, scale은 소수 자리수를 의미. float, double에는 해당 되지 않는다.

@Enumerated

enum 타입을 매핑할 때 사용한다.

속성

name
- EnumType.ORDINAL
  - enum의 순서를 DB에 저장, 이값이 Default이다.
  - 숫자로 저장되므로 데이터크기가 작아지고 빠르다. enum의 순서를 변경할 수 없는 단점이 있다.
- EnumType.STRING
  - enum이름을 DB에 저장
  - 문자로 저장되므로 데이터크기가 커지고 느리다. 하지만 enum의 순서와 상관없이 사용가능해 진다.
  - Default는 ORDINAL이지만 STRING을 더 추천 한다.

@Temporal

날짜 타입을 매핑할 때 사용 속성을 입력 하지 않으면 자바의 Date과 가장 유사한 Timestamp로 저장 된다(H2, Oracle, PostgreSQL). 하지만 이는 DB의 종류에 따라 Datetime으로 저장되기도 한다(MySQL).

속성

value
- TemporalType.DATE
  - 2013-01-23 와 같은 날짜 타입
- TemporalType.TIME
  - 11:23:18 과 같은 시간 타입
- TemporalType.TIMESTAMP
  - 2013-01-23 11:23:18 과 같이 DB의 Timestamp 타입과 매핑

@Lob

@Lob는 별도의 속성은 없다. 대신 매핑을 문자열이면 CLOB, 그외의 타입에는 BLOB으로 매핑한다.

CLOB : String, char[], java.sql.CLOB
BLOB : byte[], java.sql.BLOB

@Transient

이 필드는 매핑하지 말라는 의미이다. 이는 임시로 중간 값을 저장하는 용도로 사용가능하다.

@Access

JPA가 엔티티 데이터에 접근하는 방식, @Access를 설정하지 않으면 @Id의 설정위치에 따라 서 접근 방식이 결정 된다. @Id가 필드에 붙어 있으면 FIELD접근 방식을 의미하므로 Getter가 없어도 된다. 아이디가 프로퍼티에 있으면 PROPERTY접근 방식을 의미하게 된다. 하지만 이 두가지 방식을 섞어서 사용도 가능하다.

AccessType.FIELD : 필드 접근, Private이어도 접근 가능하다.
AccessType.PROPERTY : 프로퍼티 접근, 접근자(Getter)를 이용한다.

JPA - 3장 - 영속성 관리

Mon, 28 Nov 2016 00:00:00 +0000

※ 이 문서는 개인적인 필요에 의해 JPA 프로그래밍 책을 요약/추가 한 내용입니다.

JPA 제공 기능을 크게 2부분으로 나누면

엔티티와 테이블을 매핑하는 설계부분
매핑한 엔티티를 실제 사용하는 부분

엔티티 매니저 팩토리와 엔티티 매니저

팩토리 생성은 persistence.xml 읽어서 생성되므로 비용이 아주 많이 든다. 그러므로 하나만 만들어서 전체 프로그램이 공유해서 쓰자.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");

엔티티메니저는 비용이 많이 들지 않으므로 자주 만들어도 상관없다 단 Thread Safe 하지 않으므로 여러 쓰래드에서 공유하면 안된다

EntitiManager em = emf.createEntityManger();

영속성 컨텍스트(Persistence Context)

엔티티메니저를 하나 만들때 마다 생성되며 조회,저장 시에 엔티티 메니저는 영속성 컨텍스트에 엔티티를 보관 하게 된다. (아나의 영속성 컨텍스트를 여러 엔티티메니저가 공유도 가능하긴 하다.)

엔티티의 생명주기

비영속(new/transient) :

영속성 컨텍스트와 전혀 관계없는 상태 순수한 객체 상태, 아직 DB와 전혀 상과없는 상태 이다. em.persist()호출 이전

영속(managed):

영속성 컨텍스트에 저장된 상태 em.persist()호출 이후의 상태. 즉 영속 상태란 , 영속성 컨텍스트에 의해 관리된다는 의미이다

준영속(detached):

영속성 컨텍스트에 저장되었다가 분리된 상태 detach(), close()를 호출한 상태, em.clear()를 호출해서 영속성 컨텍스트를 초기화 해도 해당 엔티티는 준영속 상태로 유지된다

삭제(removed):

삭제된 상태 em.remove(entity)와 같이 영속성 컨텍스트와 DB에서 삭제된 상태.

영속성 컨텍스트의 특정

영속성 컨텍스트에는 @Id로 식별자가 꼭 존재해야 한다.
영속성 컨텍스트에서 DB로의 저장은 Commit(flush)시에 수행된다.
영속어 컨텍스트를 사용하면 1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기지영, 변경감지, 지영로딩 등의 장점이 존재한다.

엔티티조회

영속성 컨텍스트 내부의 캐시를 1차 캐시라 부른다. 내부에 Map형태의 정보를 저장하고 @Id로 매핑된 정보가 저장되어 있다. 즉 1차 Cache의 키는 식별자(@Id)값이다 em.find()를 호출하면 우선 1차 캐시에서 검색한다. 1차 캐시에 없다면 DB를 검색하고 결과를 1차 캐시에 저장 한다. 이를 통해서 객채의 동일성을 보장 할 수 있다

Member a = em.find(Member.class,"member1");
Member b = em.find(Member.class,"member2");

a == b (true)

엔티티 등록

엔티티 메니저는 트랜젝션을 커밋하기 전까지 엔티티를 DB에 저장하지 않고 쿼리 저장소에 INSERT SQL문을 차곡 차곡 쌓아 놓는다. 그리고 커밋시에 한번에 쿼리를 보낸다. 이것이 바로 트랜잭션을 지원하는 쓰기 지연이다. 이 기능을 잘 사용하면 모아둔 등록 쿼리를 데이터 베이스에 한번에 전달해 성능을 최적화 할 수 있다.

엔티티 수정

프로젝트가 커져가면서 수정 사항은 항상 늘어난다. SQL문으로 이러한 문제를 대처 하고 있다면 수정 사항이 생길때 마다 쿼리를 추가 하거나 수정 해야 한다. JPA에서의 엔티티 수정은 엔티티메니저에서 받아온 엔티티의 값을 변경해 줌으로써 가능 하다. 변경사항의 DB적용은 커밋 시에 저장 된다.

수정 쿼리문은 변경 사항만 가지고 만들어지지 않고 전체 필드를 이용해서 만들어진다. 이는 항상 동일한 쿼리(값은 다르지만)가 만들어진다는 장점과 용량이 커질수 있다는 단점이 있다. 용량문제가 크리티컬 하다면 hibernate의 DynamicUpdate 기능을 사용하는 방법도 있다. (30개 이상의 컬럼에서는 효과가 있다고 한다.)

변경 감시

트랜잭션을 커밋하면 엔티티메니저 내부에서 flush()가 일어나고 엔티티와 스냅샷을 비교해서 변경사항을 SQL쿼리로 만들어 SQL 저장소에 보낸다. 그리고 쓰기 지연 저장소의 SQL을 DB에 보내고 커밋한다. 변경 감시는 영속성 컨텍스트가 관리하는 영속 상태의 엔티티에만 적용된다.

엔티티 삭제

삭제를 하려면 먼저 엔티티를 조회 해야 한다. 조회된 엔티티를 넘겨주면 삭제가 된다. 이때도 당연히 삭제 쿼리는 쓰기지연 SQL 저장소에 저장 되고 커밋 시에 수행 된다.

플러시

영속성 컨텍스트의 변경 내용을 DB에 반영하는 것을 말한다.

변경 감지가 동작해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해서 수정된 정보를 찾고 쿼리로 만든다.
쓰기 지연 SQL 저장소의 쿼리를 DB로 전송하다.

플러시가 호출되는 시점은 크게 3가지가 있다.

직접호출
트랜잭션 커밋 시 자동 호출
JPQL 쿼리 실행시 자동 호출 - 아래 쿼리에서는 persist()시에는 flush가 실행되지 않지만 query를 실행하면 flush가 호출 된다. 만약 flush가 호출되지 않은면 memberA, memberB, memberC는 members에 포함되지 않을 것이기 때문이다.

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

query = em.createQuery("select m from Member m", Member.class);
List<Member> members = query.getResultList();

플러시 모드

FlushModeType.AUTO (default)
- 커밋이나 쿼리 시에 수행됨
FlushModeType.COMMIT
- 커밋시에만 수행

em.setFlushMode(FlushModeType.COMMIT);

준영속

엔티티가 영속성 컨텍스트에서 분리된 상태를 말한다. 즉 영속성 컨텍스트가 제공하는 기능을 사용할 수 없는 상태를 의미 한다. 준영속 상태로 진입하는 방법은 아래 3가지가 있다.

em.detach(entity)
em.clear()
em.close()

특징

영속성 컨택스트가 관리하지 않으므로 1차 캐시, 쓰기지연, 지연 로딩 등의 기능을 사용 할 수가 없다.
비영속과는 다르게 이미 한번 영속 상태를 거쳤기 때문에 식별자를 꼭 가지고 있다.
지연로딩을 더이상 할 수 없으므로 이와 관련된 문제가 발생할 가능성이 존재 하므로 조심해야 한다.

다시 영속 상태로 합병 (merge())

merge()를 이용하면 준영속 상태의 엔티티를 영속 상태로 변경 할 수 있다. merge는 비영속 상태의 엔티티도 합병 가능 하다. 즉 Save or Update 기능을 수행 하게 된다.

JPA - 2장 - 설정 파일 및 Database 방언

Sun, 20 Nov 2016 00:00:00 +0000

※ 이 문서는 개인적인 필요에 의해 JPA 프로그래밍 책을 요약/추가 한 내용입니다.

persistence.xml

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.1">
    <persistence-unit name="testdb">
        <properties>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="sa"/>
            <property name="javax.persistence.jdbc.password" value=""/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>

            <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect" />
            <property name="hibernate.show_sql" value="true" />
            <property name="hibernate.format_sql" value="true" />
            <property name="hibernate.use_sql_comments" value="true" />
            <property name="hibernate.id.new_generator_mappings" value="true" />
            <!--<property name="hibernate.hbm2ddl.auto" value="create" />-->
        </properties>
    </persistence-unit>
</persistence>

일반적인 persistence.xml은 위와 같은 구조(hibernate기준)를 가지고 있다.

제일 위에 아래와 같은 xml namespace 에대한 정의를 포함하는 persistence 테그로 시작한다. version=”2.1”은 JPA 2.1 버전을 사용한다는 의미이다.

<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" version="2.1">

persistence-unit 는 일반적으로 연결할 Database하나당 하나씩 생성한다고 보면 된다. 아래는 unit의 이름을 testdb로 설정 했다.

<persistence-unit name="testdb">

그리고 일반적인 JDBC접속 정보를 설정 한다. 어떤 Database이건 어떤 JPA 구현체든지 이부분은 설정해 줘야 한다. javax.persistance로 시작하는 property는 JPA 공통 설정이다.

<property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
<property name="javax.persistence.jdbc.user" value="sa"/>
<property name="javax.persistence.jdbc.password" value=""/>
<property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>

그 다음에 나오는 설정은 Database방언에 대한 설정인데, 이부분은 아래에서 좀더 자세하게 설명한다.

<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect" />

그리고 그 아래의 설정들은 hibernate에 종속된 몇가지 옵션들이 이부분은 꼭 필요한 부분은 아니다.

Database 방언(Dialect)

방언이란 서로 다른 Database간의 SQL문법 차이를 말하며 JPA 구현체들은 이를 보정해 주기 위해 Dialect Class를 제공한다 이를 통해서 Database가 변경되어도 Dialect Class교체 만으로 코드 변경없이 문제를 해결 할 수 있게 된다.

Hibernate 의 Dialect 리스트는 아래 와 같다.

Name	설명
Cache71Dialect	Caché 2007.1 dialect.
DataDirectOracle9Dialect
DB2390Dialect	An SQL dialect for DB2/390.
DB2400Dialect	An SQL dialect for DB2/400.
DB2Dialect	An SQL dialect for DB2.
DerbyDialect	Hibernate Dialect for Cloudscape 10 - aka Derby.
Dialect	Represents a dialect of SQL implemented by a particular RDBMS.
FirebirdDialect	An SQL dialect for Firebird.
FrontBaseDialect	An SQL Dialect for Frontbase.
H2Dialect	A dialect compatible with the H2 database.
HSQLDialect	An SQL dialect compatible with HSQLDB (HyperSQL). HSQLDialect.ReadUncommittedLockingStrategy
InformixDialect	Informix dialect. Seems to work with Informix Dynamic Server Version 7.31.UD3, Informix JDBC driver version 2.21JC3.
Ingres10Dialect	A SQL dialect for Ingres 10 and later versions.
Ingres9Dialect	A SQL dialect for Ingres 9.3 and later versions.
IngresDialect	An SQL dialect for Ingres 9.2.
InterbaseDialect	An SQL dialect for Interbase.
JDataStoreDialect	A Dialect for JDataStore.
MckoiDialect	An SQL dialect compatible with McKoi SQL.
MimerSQLDialect	An Hibernate 3 SQL dialect for Mimer SQL.
MySQL5Dialect	An SQL dialect for MySQL 5.x specific features.
MySQL5InnoDBDialect MySQLDialect	An SQL dialect for MySQL (prior to 5.x).
MySQLInnoDBDialect
MySQLMyISAMDialect
Oracle10gDialect	A dialect specifically for use with Oracle 10g.
Oracle8iDialect	A dialect for Oracle 8i.
Oracle9Dialect	Deprecated. Use either Oracle9iDialect or Oracle10gDialect instead
Oracle9iDialect	A dialect for Oracle 9i databases.
OracleDialect	Deprecated. Use Oracle8iDialect instead.
PointbaseDialect	A Dialect for Pointbase.
PostgresPlusDialect	An SQL dialect for Postgres Plus
PostgreSQLDialect	An SQL dialect for Postgres For discussion of BLOB “support” in postrges, as of 8.4, have a peek at http://jdbc.postgresql.org/documentation/84/binary-data.html.
ProgressDialect	An SQL dialect compatible with Progress 9.1C Connection Parameters required: hibernate.dialect org.hibernate.sql.ProgressDialect hibernate.driver com.progress.sql.jdbc.JdbcProgressDriver hibernate.url jdbc:JdbcProgress:T:host:port:dbname;WorkArounds=536870912 hibernate.username username hibernate.password password The WorkArounds parameter in the URL is required to avoid an error in the Progress 9.1C JDBC driver related to PreparedStatements.
RDMSOS2200Dialect	This is the Hibernate dialect for the Unisys 2200 Relational Database (RDMS).
ResultColumnReferenceStrategy	Defines how we need to reference columns in the group-by, having, and order-by clauses.
SAPDBDialect	An SQL dialect compatible with SAP DB.
SQLServer2008Dialect	A dialect for Microsoft SQL Server 2008 with JDBC Driver 3.0 and above
SQLServerDialect	A dialect for Microsoft SQL Server 2000 and 2005
Sybase11Dialect	A SQL dialect suitable for use with Sybase 11.9.2 (specifically: avoids ANSI JOIN syntax)
SybaseAnywhereDialect	SQL Dialect for Sybase Anywhere extending Sybase (Enterprise) Dialect (Tested on ASA 8.x)
SybaseASE15Dialect	An SQL dialect targetting Sybase Adaptive Server Enterprise (ASE) 15 and higher.
SybaseDialect	Deprecated. use AbstractTransactSQLDialect, SybaseASE15Dialect or SQLServerDialect instead depending on need.
TeradataDialect	A dialect for the Teradata database created by MCR as part of the dialect certification process.
TimesTenDialect	A SQL dialect for TimesTen 5.1.

Spring-Boot embedded tomcat 에 access log 설정 하기

Mon, 01 Aug 2016 00:00:00 +0000

Embedded tomcat을 사용하는 Spring-Boot 프로젝트에서 Access log를 설정하는 방법

application.properties 설정

server.tomcat.accesslog.pattern=%{yyyy-MM-dd HH:mm:ss}t\t%s\t%r\t%{User-Agent}i\t%{Referer}i\t%a\t%b   
server.tomcat.accesslog.enabled=true   
server.tomcat.basedir=.

생성되는 파일 예제

access_log.2016-08-01.log

파일 내용 예제

2016-08-01 09:54:56        200      GET /favicon.ico HTTP/1.1 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36    http://localhost:8880/click?appId=ABBC10E8E1F81E4AF16B98BDF12E7C3C14697712660000&telCo=2&profileId=1&clientTm=12312312&clientStore=aaaa&productId=pppid&packageName=123123  0:0:0:0:0:0:0:1      946

Pattern Reference

아래 항목은 미리 설정된 값으로 Logging 시에 해당 값으로 변환되어 저장 된다.

%a - Remote IP address
%A - Local IP address
%b - Bytes sent, excluding HTTP headers, or ‘-‘ if no bytes were sent
%B - Bytes sent, excluding HTTP headers
%h - Remote host name (or IP address if enableLookups for the connector is false)
%H - Request protocol
%l - Remote logical username from identd (always returns ‘-‘)
%m - Request method
%p - Local port
%q - Query string (prepended with a ‘?’ if it exists, otherwise an empty string
%r - First line of the request
%s - HTTP status code of the response
%S - User session ID
%t - Date and time, in Common Log Format format
%u - Remote user that was authenticated
%U - Requested URL path
%v - Local server name
%D - Time taken to process the request, in millis
%T - Time taken to process the request, in seconds
%I - current Request thread name (can compare later with stacktraces)

추가 적으로 Header 나 Cookie등에서 특정 정보를 취득할 수 도 있다.

common - %h %l %u %t "%r" %s %b   
combined - %h %l %u %t "%r" %s %b **"%{Referer}i"** **"%{User-Agent}i"**

%{xxx}i Request Header 내의 정보
%{xxx}o Response Header 내의 정보
%{xxx}c 특정 Cookie 내용
%{xxx}r ServletRequest 의 특정 attribute
%{xxx}s HttpSession 의 특정 attribute
%{xxx}t DateFormat을 출력하기 위한 옵션

escape() vs encodeURI() vs encodeURIComponent()

Wed, 20 Jul 2016 00:00:00 +0000

보통 javascript에서 URI를encoding하는 방법에는 3가지가 존재 한다. encoding이란 통신상에서 잘못된 정보를 주고 받지 않도록 하기 위해 한글과 같은 2바이트 문자열이나 특수문자등을 ASCII형태의 문자로 변환하는 것을 말한다.

1. escape()

아래의 문자열을 제외한 모든 문자는 %XX나 %uXXXX 형태의 16진수를 문자열로 나타넨 형식으로 변환된다.

ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890 @*-_+./

2. encodeURI()

함수 이름에서도 알 수 있듯이 URI 전체를 encoding 할때 사용되는 함수 이다. URI에 사용되는 특수 문자(: ; / = ? &)를 encoding 하지 않는 다는 것만 빼고 escape()와 동일하다.

3. encodeURIComponent()

함수 이름에서도 할 수 있듯이 URI 전체가 아닌 부분부분을 encoding할때 사용하는 함수 이다. URI에 사용되는 특수 문자(: ; / = ? &)까지 encoding 된다는 것만 빼고 escape()와 동일하다.

URI에 사용되는 특수 문자가 encoding 되므로 URI 전체를 encoding 하는 경우 URI가 아닌 하나의 문자열로 인식 되게 되므로 주의 해야 한다. URI의 Parameter의 Value값을 encoding할때 주로 사용되게 된다.

예제

var str="http://test.com/user.jsp?name=홍 길동&phone=010-123-1234";

console.log("escape()            ="+escape(str));
console.log("encodeURI()         ="+encodeURI(str));
console.log("encodeURIComponent()="+encodeURIComponent(str));


---- 결과 ----
escape()            =http%3A//test.com/user.jsp%3Fname%3D%uD64D%20%uAE38%uB3D9%26phone%3D010-123-1234
encodeURI()         =http://test.com/user.jsp?name=%ED%99%8D%20%EA%B8%B8%EB%8F%99&phone=010-123-1234
encodeURIComponent()=http%3A%2F%2Ftest.com%2Fuser.jsp%3Fname%3D%ED%99%8D%20%EA%B8%B8%EB%8F%99%26phone%3D010-123-1234

Welcome to Jekyll!

Tue, 18 Aug 2015 15:07:19 +0000

You’ll find this post in your _posts directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run jekyll serve, which launches a web server and auto-regenerates your site when a file is updated.

To add new posts, simply add a file in the _posts directory that follows the convention YYYY-MM-DD-name-of-post.ext and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.

Check out the Jekyll docs for more info on how to get the most out of Jekyll. File all bugs/feature requests at Jekyll’s GitHub repo. If you have questions, you can ask them on Jekyll’s dedicated Help repository.