2012-10-19 5 views
2

JPA 2의 CriteriaBuilder 클래스가 이러한 쿼리를 만드는 것이 왜 가능한지 궁금합니다. 내가 User 클래스에 지속성이 String이고 name이라는 속성이 있다고 가정 해 보겠습니다. 왜 이것을 쓸 수 있습니까?JPA에서 CriteriaBuilder를 사용하면 왜 관련없는 유형간에 불확실한 술어를 만들 수 있습니까?

CriteriaBuilder builder = mgr.getCriteriaBuilder(); 

CriteriaQuery<User> crit = builder.createQuery(User.class); 
Root<User> user = crit.from(User.class);      // 1 
crit.select(user) 
    .where(builder.equal(user.get(User_.name), 2.5));  // 2 

먼저 마커 1 : User.class을 다시 표시해야하는 이유는 무엇입니까? 내 CriteriaQuery가 내가 사용자에게 관심을 가지고 있음을 알고 있다고 생각하지 않습니까? 다른 클래스를 여기에 주입 할 수 있도록 유형 안전을 중단하지 않습니까?

두 번째로 마커 2 : name 속성은 String입니다. String을 이중으로 비교하면 왜 이런 말도 안되는 것을 컴파일 할 수 있습니까?

public Predicate equal(Expression<?> x, Object y) 

대신으로이 따르는 아마도 많은 종류 안전 버전 : 즉, 왜라는 equal 방법이의 서명은?

public <T> Predicate equal(Expression<T> x, T y) 

Querydsl과 같은 다른 쿼리 프레임 워크로이 문제를 해결할 수 있습니까?

답변

2

JPA 2 Criteria API의 유형 안전성 측면은 사양 프로세스의 꽤 늦은 시점에 추가되었다고 생각합니다. 그것이 일관성을 느끼지 않는 이유입니다.

Querydsl은 JPA 2 Criteria API보다 간결하며 더 형식 안전합니다. Querydsl은 프리디 케이트 생성을 위해 팩토리 클래스 대신 유창한 빌더를 사용하므로 동일한 메소드가 여기에 있습니다. http://www.querydsl.com/static/querydsl/2.8.0/apidocs/com/mysema/query/types/expr/SimpleExpression.html#eq%28T%29

저는 Querydsl의 관리자입니다.이 답변은 편향되어 있습니다.

+0

방금 ​​Querydsl을 자세히 살펴 봤습니다. 나는 그것을 좋아한다. 유일한 단점은 종속성의 수입니다. 나는 정말로 그들 모두가 필요합니까? 어느 항아리가 어떤 특징을 위해 필요하다고 말하는가? –

+0

어떤 종속성에 대해 우려하고 계십니까? 종속성이 어떤 기능에 사용되는지를 선언하는 문서는 없습니다. –

+0

좋은 JPA 쿼리를 원한다면 antlr, asm, glib, ecj, guava, validation-api와 같은 것들이 필요합니까? –

2

특정 JPA에서는 컴파일 타임 모델 생성이 필요없는 Object Query 또는 Torpedo Query (그러나 HQL에 특화되어 있음)을 사용할 수도 있습니다. 어쨌든 QueryDsl은 형식 안전 쿼리를 구현 한 첫 번째 사람 중 하나입니다