2010-04-08 2 views
2

JP30에서 mappedBy을 사용하여 매핑 된 여러 컬렉션에이 엔티티가있는 em.remove(entity)을 처리하는 것이 가장 좋습니다. Descriptor하는 BusinessObjectLevel 기업 : mappedBy 컬렉션과 관련된 엔티티를 제거 할 때 가장 좋은 방법은 무엇입니까?

세 가지 다른 엔티티를 참조하는 Property 같은 엔티티를 고려하십시오. 매핑은 Property 엔터티에 @ManyToOne을 사용하고 다른 세 개체에는 @OneToMany(mappedBy...)을 사용하여 정의됩니다. 역 매핑은 해당 컬렉션에 액세스해야하는 몇 가지 상황이 있기 때문에 정의됩니다.

em.remove(prop)을 사용하여 속성을 제거 할 때마다이 요소는 다른 세 가지 유형의 관리 된 엔터티에서 자동으로 제거되지 않습니다. 신경 쓰지 않고 다음 페이지로드 (webapp)가 해당 엔티티를 다시로드하지 않으면 속성이 발견되고 더 이상 사실이 아닌 결정을 내릴 수 있습니다.

반비례 매핑은 꽤 커질 수 있습니다.하지만 그때까지는 지연로드되었을 수있는 모든 속성을로드하기 때문에 descriptor.getProperties().remove(prop)과 같은 것을 사용하고 싶지는 않습니다.

현재 관리중인 엔티티를 새로 고치는 것이 좋습니다 : if (em.contains(descriptor)) em.refresh(descriptor) -로드 된 컬렉션을 언로드하고 다음 액세스시 다시로드를 트리거합니다.

이미로드 된 entites의 모든 mappedBy 컬렉션을 처리 할 수있는 또 다른 방법이 있습니까?

답변

1

엔티티가 우수하게 관리되는지 확인하는 솔루션입니다.

엔티티의 @PreRemove 및 @PrePersist에서 왜 프로그래밍하지 않습니까? 이렇게하면 단 한 번만 프로그래밍하면 모델을 항상 일관되게 유지할 수 있습니다 (수동 수집을 변경하지 않고도).

다른 해결책은 업데이트 및 삽입 후 항상 리디렉션하는 것이므로 조작 된 모델 객체를 사용하는 대신 컨트롤러가 JPA를 쿼리해야합니다.

업데이트 : 당신은 또한 체크 아웃 할 수 있습니다 : 당신의 생각에 대한 JPA implementation patterns

+0

감사합니다. 지속성 이벤트를 사용하는 것은 다소 까다로운 일일 것입니다. 왜냐하면 지금까지 모델은 entitymanager 자체를 참조하지 않고 Seam 컨텍스트에서 사용되기 때문에 새로 고침 방법이 작동하지 않을 수 있습니다. 그리고 관련된 콜렉션에 대한 add()/remove()는 큰 콜렉션에 너무 비싸다. –

+0

현재 구현을 어느 정도 승인했기 때문에 솔루션을 수락했습니다. 퍼시스턴스 이벤트의 아이디어는 어떤 경우에는 유용하고 유용합니다. –

관련 문제