http://wiki.eclipse.org/EclipseLink/Examples/JPA/Pagination

 위 내용 중 쉽게 쓸만 한 것은 아래 코드이다.
Query query = em.createQuery("SELECT e FROM Employee e ORDER BY e.lastName ASC, e.firstName ASC");
query.setFirstResult(5);
query.setMaxResults(5);
List emps = query.getResultList();

예제에는 오라클이라 되어 있는데 MySQL도 사용 가능하다.






 
설치된 Java 환경이 SE 인가 EE인가 살펴보자..

 



one-to-one 및 many-to-one일 경우
SE 환경에서는 JPA가 fetch 무시하고 EAGER로 적용해버린다. 

고로.. SE에서는 쓸모가 없다.. ;; 


http://www.java2s.com/Code/Java/JPA/CatalogJPA.htm

잘 되어 있고 코드도 어렵지 않다. 


http://www.objectdb.com/java/jpa/persistence

JPA 각 클래스 및 짤막한 예제 코드가 있는 곳. 


<01. package 생성>
src 하위에 자신만의 package를 생성한다. 

<02. Table 가져오기>
만든 패키지에서 우클릭 후 JPA Entities from Tables를 눌러 아래 화면으로 이동한다.
만약, MySQL Workbench를 이용한다면 DB 모델링을 끝마친후 DB를 생성한 다음 이 작업을 하게 되는데
모델링된 결과를 바로 Java로 가지고 올 수 있어 편하다.
 

<03. DB 접속>
프로젝트 생성시 만들었던 DB Connection을 이용해 DB내의 Table 정보를 보여준다. 
Java로 가져올 Table(Entity)를 선택한다. 

<03-1. 관계설정>
만약 Entity간의 관계가 설정이 되어 있다면 자동으로 관계를 설정해준다.
이는 Entity 설정에 의한 자동 매핑으로 Entity에 관계 설정이 없다면 단일 테이블(Entity)로 판단하고 관계를 생성하지 않는다. 

<03-2. 추가 설정>
먼저 PK 생성 방법, 늦은 로딩 등을 설정할 수가 있다. 
여기서 관계를 표현하기 위한 방법을 지정하여야 하는데, 1:N의 관계라면 N을 표현할 type을 지정해준다.
List가 편하기에 List로 설정 한 것.

만약 확장(extends)해야 할 클래스가 있따면 Superclass에 적어주면 되고
어떤 인터페이스를 구현해야 할 경우도 interfaces에 적어주면 된다.
 

<03-4. 테이블 변환 정보>
각 테이블이 자바로 변환될 때 표현될 필드와 클래스 이름을 표시해준다.
접근자와 각 컬럼(필드)별 이름을 별도 지정해 줄 수 있다. 

<04. Table을 java로 가져온 결과>
PK가 붙은 파일은 복합 키 구조일 경우 자동으로 생성되는 파일이다.

 
추가 작업은 Spring 3.1, myBatis 설정 추가와 JPA와 Spring을 이어줄 JPA Dialect를 만들어 주는 것 정도?


<01. 웹 프로젝트 생성>



<02. Project 설정>
중간에 보이는 Configuration을 바꿔주어야 한다.
여기서 그냥 Finish를 눌러서 프로젝트 정보에서도 가능하나, 만들때 하기로 한다.

Modify를 누러서 진행 

<03. JPA 설정>
JPA를 선택하고 Runtimes에 Tomcat을 선택한다. 현재 JPA Version은 2.0으로 되어 있다. 

<04. JPA Library 다운로드>
플랫폼은 EclipselInk 2.4를 사용할 것이고 해당 라이브러리는 Download 버튼을 누르면 아래처럼 창이 나온다. 

<05. Library 다운로드>
각 환경에 맞는 EclipseLink를 선택한 후 Next를 눌러 다운로드를 완료한다. 

<06. 추가 라이브러리 설정>
JPA에 필요한 Hibernate 관련 라이브러리를 추가해주어야 한다. 
다운로드 버튼 위 라이브러리 구성 화면으로 들어가 아래 화면으로 이동한다.

이 화면에서 Add External JARs로 이동해 HIbernate JAR 파일을 추가해준다.
최신 라이브러리를 넣으면 되며 라이브러리는 www.hibernate.org 에서 구할수 있다. 

<07. 라이브러리 추가>
OK를 누르고 Finish를 누른다.
06 화면에서 라이브러리 설정 아래 Connection이 있는데, MySQL로 설정을 해주자.
Add Connection을 눌러 아래 화면으로 이동한다.
 

<08. MySQL Connection 추가>
Name을 바꿔주고 Next 

<08-1. Driver 추가 및 설정>
기존에 만들어 놓은게 있어 나타나지만, 처음 만들경우 아무것도 나타나지 않는다.
Drivers 우측에 있는 + 아이콘을 눌러 추가 화면으로 이동한다. 

<08-2. DB Connection 정보 입력>
자신의 정보에 맞게 입력해준다. 

<08-3. 완료된 설정 화면>

<09. 프로젝트 생성 완료 화면>
Finish를 눌러 프로젝트 생성을 완료한다. 

Server OS : Ubuntu 10.04
MySQL : 5.5.28, for debian-linux-gnu (x86_64) using readline 6.2


MySQL 역시 샘플 DB를 제공한다.

160MB 정도의 대용량을 샘플로 제공하는데, 이를 통해 JPA 프로젝트 생성을 할 수 있다.
샘플 DB의 Table역시 각 관계가 설정되어 있어 JPA에서 관계를 어떻게 표현하는지 알 수 있기에 다른 샘플 DB보다 적합하다.

자세한 것은 아래 URL을 참조.
http://dev.mysql.com/doc/employee/en/employees-introduction.html 

MySQL Example Database download
https://launchpad.net/test-db/employees-db-1/1.0.6/+download/employees_db-full-1.0.6.tar.bz2

실행 법은 압축을 풀고 콘솔창에서 mysql -u root -p employees < employees.sql 
sql 파일 하나만으로는 불가능하다.
sql을 살펴보면 dump 내용을 복원하는 것이기 때문에 압축 파일 내의 모든 파일이 필요하다.

DB 생성 후 각 테이블을 살펴보면..

select count(dept_no) from departments  -- 9
select count(emp_no) from employees  -- 300024
select count(emp_no) from dept_emp -- 331603
select count(dept_no) from dept_manager -- 24
select count(emp_no) from salaries -- 2844047
select count(emp_no) from titles -- 443308

자료가 상당히 많아서 아주 좋다.

 
원글 : http://techblog.bozho.net/?p=358)**

이 글을 Korea Spring User Group의 송준이 <socurites@gmail.com>  님이 번역을 하여 글을 퍼옵니다.


 *지독하게 해로운 프레임워크, 그리고 복잡함*
     
    *(*http://techblog.bozho.net/?p=358)**
     
    2011년 4월 29일
      
    하이버네이트와 스프링같은 프레임어크는 업계 표준이다. JSF, EJB 등도 또한 업계 표준으로 많은 어플리케이션에 사용된다. 하지만
    프레임워크 사용을 반대하는 사람들은 항시 있기 마련이다. 다루려는 주제는 "언어 불가지론(language-agnostic)"에 대한
    것이고 자바를 예로 들겠지만, 모든 언어에 적용되는 내용이다.
     
     
    프레임워크를 반대하는 일반적인 근거는 다음과 같다.
     
    - 프레임워크는 매우 복잡하고, 사용할 필요가 없다
     
    - 더 효과적인 프레임워크를 직접 만들 수 있다.
     
    - 프레임워크가 품질이 높을 것 같지 않으며, 필요한 작업을 해줄 것 같지도 않다.
     
    - 프레임워크를 추가적으로 배울 필요가 없으며, 코어 자바로도 충분하다.
     
    - "프레임워크가 그렇게도 좋아?"라는 말을 한번도 들어본적이 없다.
     
      
    안타까운 점은 이렇게 믿는 사람들과 말이 통하지 않는다는 점이다. 게다가 이 부류의 사람들이 프로젝트를 이끄는 리더거나 아키텍트가
    되버리면, 결국 프로젝트는 망한다. 그래도 오해는 하지 말기 바란다. 이들 프레임워크를 사용하지 않고도 성공하는 프로젝트도 꽤 있다. 하지만
    이 프로젝트들은 일반적인 경우는 아니다. 위의 논거들을 조목조목 다뤄보도록 하자.
     
     
    "프레임워크는 매우 복잡하고, 사용할 필요가 없다" - 복잡도는 사실 프레임워크에서 나타나는 문제점이다. 프레임워크를 처음 익힐 때는
    일주일이 걸린다. 하지만 시작할 때만 어려울 뿐이고, 한번 익히고 나면 팀은 프레임워크를 능숙하게 다룰 수 있게 된다. 결국 특정
    수준정도로 어려울 뿐이다. 내 경험을 빌려 이 점을 확실히 알 수 있다. 지금 일하는 회사에 왔을 때, 회사에서는 스프링과 하이버네이트를
    사용해 대규모의 프로젝트를 진행하고 있었다. 일주일 가량 지나자 나는 이 프로젝트에서 무엇이든 변경할 수 있게 되었다. 스프링을 적용한
    프로젝트는 복잡도가 증가하는 게 아니라 그저 규모가 커질 뿐이고, 복잡도는 특정 수준에 그칠 뿐이다. 이 복잡도는 알고리즘에 관련된게
    아니라, 구조와 설정에 관련된다.
     
      
    다음으로 "더 효과적인 프레임워크를 직접 만들 수 있다"는 주장이 가진 문제점을 살펴보자. 프레임워크를 직접 만들게되면, 복잡도는 한없이
    증가하기 쉽다. 항상 그렇지는 않지만, 직접 프레임워크를 만들고 바귀를 다시 발명하게 되면 프로젝트를 유지하기에 어려울 때가 많다.
     
      
    일하는 팀이 5명내지 6명으로 구성되고, 팀원은 비즈니스 가치를 이끌어내야지 프레임워크를 작성할 시간이 부족하다는 점은 말할 필요도 없다.
    오픈소스 프레임워크에 수천 시간을 들이고, 이 프레임워크를 개발하고 생길 수 있는 모든 종류의 이슈와 문제점을 찾느라 수백만 시간을
    들였다는 점을 생각해볼 때, "프레임워크가 품질이 높을 것 같지 않으며, 필요한 작업을 해줄 것 같지도 않다"는 주장은 근거가 없어
    보인다. 널리 쓰이는 프레임워크는 평범한 팀에서 프로젝트 일정에 맞춰서 만들 수 있는 프레임워크이 비해 품질이 훨씬 높다.
     
     
     하지만 다른 방향에서 접근하는 사람들도 있기 마련인데, 바로 "과도한 설계'다. 내 생각에 과도한 설계는 프로젝트에서 있을 수 있는 가장
    큰 문제다. 그리고 "프레임워크를 추가적으로 배울 필요가 없으며, 코어 자바로도 충분하다"는 근거가 요점을 제대로 짚은 것처럼 보인다. 하지만
    이 주장은 "능력이 부족하거나 배울 실력이 안되며 배우고자하는 의지가 없다"는 말을 속여서 말한 것에 지나지 않는다. 나는 프레임워크에
    대해 불평하는 일(stackoverflow.com에 있는 질문들을 포함해)을 많이 봐왔다. 스프링은 쓸데 없이 복잡하고
    비대해졌으며, 하이버네이트는
    제어권을 개발자로부터 빼았고, 문제점들을 많이 만들어낸다는 것이다. 왜 이들 주장이 확실히 잘못된 것인지는 설명하지 않겠다. 하지만
    사람들이 이들 프레임워크를 잘 이해하지 못했기에 이처럼 주장하는 것이다. 그리고 겉보기에 더 쉬운 방법을 선택하게 되면 결국 실망만
    가져올 뿐이다.
      
     
    반대로 잘 알지도 못하면서 프레임워크가 유행하기 때문에 도입하려는 사람들도 있다. 결국 이들은 프레임워크를 비난하게 된다. 이들 사이에
    공통적인 테마가 있음을 알 수 있다. 문제는 프레임워크가 아니라, 프레임워크를 이해하지 못하는 사람이다.
      
     
    그렇긴 해도 프레림워크는 모두 훌륭하다는 뜻은 아니다. EJB2는 별로였다. 스트럿츠 1도 벼로였다. 하지만 프레임워크를 비난한 입장이
    되려면 진짜 문제가 무엇인지 그리고 어떻게 고쳐야 하는지 알아야만 한다. 개빈 킹과 로드 존슨은 깨달았다. 다른 이들은 EJB 2를
    사용했고, 이는 "아마도" 직접 만든 프레임워크를 사용한 것이 비하면 더 나은 선택이었을 것이다. 뭐 당신이 수퍼 아키텍트라서 직접 만든
    프레임워크가 더 낫다고 치자. 그렇다면, 스프링/하이버네이드/기타 등등의 프레임워크를 압도하는 사이트의 링크를 부담 갖지 말고 알려주기
    바란다.
     
      
    이렇게까지 말하고 나면 "프레임워크 반대론자"는 "도대체 왜 새롭게 나오는 프레임워크들을 모두 배워야 하지"라고 악을 쓸수 있다. 먼저,
    배운만큼 얻기 마련인데, 어쨌든 새로운 것을 매일 익혀야하기 때문이다. 두번째로는 인기 있는 프레임워크는 최선의 방법과 개념들을 보급하기
    때문이다. 프레임워크 통해 흔히 생기는 상황에 대처하는 최선의 방법을 배울 수 있다. 또 다른 장점으로 스프링에 정통해지면 다른 의존성
    주입을 활용하는 프레임워크를 쉽게 배울 수 있으며, 하이버네이트 전문가가 되면 어떤 ORM도(실제로는 객체를 객체지향이 아닌
    데이터에비스에 매핑하는 어떤 툴도(NoSQL을 포함해)) 쉽게 배울 수 있다. 다시 말하면, 설정 방법과 메서드 사용법이 문서화되어 있고,
    쉽게 확인할 수 있다. 프레임워크에서 중요한 건 바로 개념이다.
      
     
    따라서 중요한 것은 프레임워크를 도입할 지, 장단점을 제대로 평가할 수 있을지, 그리고 당면한 프로젝트에 적합한지 선택하는 사람들의
    능력과 이해 정도다. 프레임워크는 수월하게 개발하기 위해 만들여졌지, 복잡하게 만들려고 만들어진게 아니다. 시작할 때는 어려움이 따르지만,
    프레임워크를 제대로 선택했다면 이후로는 복잡도를 생각하는 것보다는 낮은 수준으로 맞출 수 있다.



아주 좋은 글이다.

     

description : only one may be defined as writable all others must be specified read-only

Many To One 매핑에서 자주 발생하는 문제이다..
또한 추가적으로 One쪽 PK가 Many쪽에서도 PK로 사용된다면 JPA 초기 설정된 상태로는 100% 에러난다.

A와 B의 관계가 N:1이면 A와 B의 PK들은 아래의 구조를 가지게 된다.


	//MasterCodes.java (A와 B의 관계에선 A, 즉 Many 쪽 table)
	@EmbeddedId
	private MasterCodesPK id; //복합키

	@Column(name="CODE_NAME")
	private String codeName;

	//생략~~

	//bi-directional many-to-one association to MasterCodeGroups
	@ManyToOne(cascade = REFRESH)
	@JoinColumn(name="CODE_GROUP_SEQ")
	private MasterCodeGroups masterCodeGroup;
	
	// getter / setter 생략~
	//MasterCodeGroups.java (A와 B의 관계에선 B, 즉 One에 해당)
	@Id
	@Column(name="CODE_GROUP_SEQ")
	@GeneratedValue(generator = "MASTER_CODE_GROUPS")
	private int codeGroupSeq;

	@Column(name="CODE_GROUP_NAME")
	private String codeGroupName;

	// 생략~~

	//bi-directional many-to-one association to MasterCodes
	@OneToMany(mappedBy="masterCodeGroup", cascade = REFRESH)
	private Set masterCodes;

	// getter - setter 생략~


위 내용이 JPA로 Table에서 불러와 세팅 된 것인데 이대로 했다가 에러가 빵 뜨더라..;;
그 에러가 제목과 같은 에러인데 -
복합키로 구성될 경우 자신의 PK가 아닌 다른 Table의 PK를 변경할 수 있다면? 있을수 없는 일이다;;
즉 A와 B에서 A의 키는 A_PK, B_PK를 사용하는데 A테이블에서 B_PK를 변경할 수 있다면? 무결성이 깨지게 된다.;;
이때는 차라리 B에서 B_PK가 변경된다면 A에서도 B_PK가 변경되게 제약 조건을 설정하는게 좋다 -

그래서 read-only로 하라는 에러가 나오는 것인데 -

아래와 같이 A테이블에 설정을 더 적어 주어야 한다..


	//MasterCodes.java (A와 B의 관계에선 A, 즉 Many 쪽 table)
	@EmbeddedId
	private MasterCodesPK id; //복합키

	@Column(name="CODE_NAME")
	private String codeName;

	//생략~~

	//bi-directional many-to-one association to MasterCodeGroups
	@ManyToOne(cascade = REFRESH)
	@JoinColumn(name="CODE_GROUP_SEQ", nullable=false, insertable=false, updatable=false)
	private MasterCodeGroups masterCodeGroup;
	
	// getter / setter 생략~



아까와 동일하나 JoinColumn Annotation에 기타 속성이 잔뜩 들어갔다;; 저렇게하면 read-only가 된다.

시간이 없어서 문서를 다 읽어보지 않고 중요 부분만 읽은 후에 썼는데 -
시간 있으신 분은 아래 사이트에서 다 읽어보면 좋을 것 같다.

http://trycatchfinally.blogspot.com/2006/01/mapping-relationships-in-ejb-30.html

+ Recent posts