2011-03-16 2 views
1

두 가지 클래스가 있습니다. 소프트웨어, 태그 - ManyToMany와 관련이 있습니다. 우리는 태그를 넣지 않고 소프트웨어를 만들 수 없습니다.무수히 많은 것을 보존하고 무결성을 보존 할 때

@Test public void createSoftwareWithNullTags() {

List<Tag> tags = null; 
    Software software = new Software("software1", "description1", tags); 
    try { 
     software.save(); 
     fail("tags should not be null"); 
    } catch (Exception ex) { 
     // NEVER COME HERE !!! 
    } 

} 

그래서,이 테스트가 실패 :

나는 확인 테스트를 작성하고자합니다. 나는 그것이 SOFTWARE_TAG 테이블에 데이터를 저장하려고 시도하지 않기 때문에 그 경우에는 좋은 테스트가 아닐 것이라고 생각한다. 물론 수동으로 유효성 검사를 할 수 있지만 일부 주석이나 무언가를 사용하여 최대 절전 모드로 구현하고 싶습니다. 가능한가? 아니면 어떻게할까요?

내 엔티티 :

@Entity public class Tag extends Model {

public String title; 

public Tag(String title) { 
    this.title = title; 
} 

@ManyToMany(
    cascade = {CascadeType.ALL}, 
    mappedBy = "tags", 
    targetEntity = Software.class 
) 
public List<Software> softwares; 

}

@Entity public class Software extends Model {

public String title; 
public String description; 

@ManyToOne(optional = false) 
public Author author; 


@ManyToMany(cascade = CascadeType.ALL) 
@JoinTable(

     name = "SOFTWARE_TAG", 
     joinColumns = @JoinColumn(name = "Software_id"), 
     inverseJoinColumns = @JoinColumn(name = "Tag_id") 

) 
public List<Tag> tags; 

public Software(String title, String description, Author author, List<Tag> tags) { 
    this.title = title; 
    this.description = description; 
    this.author = author; 
    this.tags = tags; 
} 

}

답변

1

최대 절전 모드의 M : N은 약간 까다 롭고 시나리오에 적합하지 않습니다. 나는에 추천 할 것이다 :

  • 2 개의 rels 1 : M로 M : N 관계를 변환하십시오. 소프트웨어 - 중산층 - 태그. 그렇게하면 소프트웨어 측에 @ 필수 항목을 추가 할 수 있고 더 간단한 1 : M 옵션으로 작업 할 수 있습니다. 현재 M을 유지하는 경우

에 대한 일부 사용자 유효성 검사를 추가 : N, 당신의 cascade 속성을 변경해야합니다. 소프트웨어 엔터티를 제거하면 관련 태그 (다른 소프트웨어 엔터티에서 사용할 수있는)를 모두 제거하고 혼란을 야기 할 것이라고 나는 말할 것입니다.

2

당신은 "일반"함께 할 수없는 최대 절전 모드. "Bean Validation"JSR의 구현 인 Hibernate Validator를 사용해야 할 것이다. 이 특정한 경우에, 당신은, 말의 min 속성, 1

http://docs.jboss.org/hibernate/validator/4.2/reference/en-US/html_single/#validator-defineconstraints-builtin

편집을 @Size 주석을 사용하십시오 : 정말 당신이 기대하지 않는 경우 NullPointerException이 던져 고려해야한다고 생각합니다 파라미터는 null가됩니다. 제 의견으로는, "사용자"오류를 막기 위해 Bean Validation 을 사용해야합니다. 실수로 프로그래밍하지 못하게하려면 (예 : 허용되지 않는 null과 같이) 예외 상황을 고수해야합니다.

+0

플레이 프레임 워크는 임베디드 된 최대 절전 모드를 사용하므로 어떤 버전의 유효성 검사 프레임 워크를 사용해야하는지 생각해야하므로 추가 프레임 워크를 사용하고 싶지 않습니다. 하지만 그것은 문제가되지 않을 수도 있습니다 ... 그리고 나는 어디에 넣어야하는지 모르겠다. – ses

관련 문제