2010-01-04 2 views
0

문제점 : 엔티티 (사용자라고 함)는 UI에서 페이지 매김 방식으로 표시됩니다. 또한 UI는 각 엔티티에 대한 체크 박스를 표시하므로 관리자가 사용자를 다중 선택하고 삭제할 수 있습니다. 이 엔티티가 외래 키 관계를 통해 다른 많은 엔티티와 연결되어 있다는 것은 당연합니다 (그로 인해 생성 된 구매 주문)외래 키 관계가있는 많은 JPA 엔티티의 삭제를 처리하는 방법

구매 주문서가 특정 사용자와 연결되어 있으면 사용자 삭제가 불가능합니다. 외래 키 위반. 마찬가지로 사용자가 다른 여러 테이블과 관계를 가질 수 있습니다.

엔터티를 삭제할 수없는 경우 삭제 확인란을 표시하지 않는 것이 좋습니다. 그러한 점검이 필요한 경우, 각 사용자 행에 대한 사용자 목록 페이지를 구성하는 동안 가능한 관계에 대해 종속 테이블을 조회해야합니다. 많은 사용자가있는 경우 비용이 많이 소요될 수 있습니다.

우아한 방법으로이 문제를 해결하기위한 제안 된 접근 방법은 무엇입니까?

답변

5

다섯 가지 방법이 내 마음에 와서 :와

  1. 선언 모든 종속성 cascade=CascadeType.DELETE (또는 ALL). 그러면 모두 삭제되지만, 이는 거의 원하는 동작이 아닙니다.
  2. 모든 체크 박스를 표시하고 사용자를 하나씩 삭제 (session.remove()/entityManager.remove() 사용)하고 ConstraintViolationException을 잡습니다. 같은 뭔가 :이 경우, 당신은 예외가 적시에 던져되도록 EntityManagerFlushMode을 설정해야 할 수도

    for (User user : usersToDelete) { 
        try { 
         entityManager.remove(user); // or dao.remove(), 
                // or someService.remove() 
        } catch (Exception ex) { 
         // verify if the there is `ConstraintViolationException` 
         // in the exception chain, and log a short message about the failure 
         // If the exception is elsewhere, then log the whole exception 
         // or rethrow 
        } 
    } 
    

    참고.

  3. 사용자 (또는 동일한 시나리오의 모든 개체)의 제약 조건을 검사하는 데이터베이스 관련 코드를 작성하십시오. 나는 어떤 레코드가 현재 레코드에 의존하는지 정확하게 보여주기 때문에 이것을 한 번했습니다. 삭제에 대한 데이터베이스 별 검사를 수행 했으므로 모든 사용자가 확인란을 다시 사용했습니다.

  4. 말했듯이 모든 결과를 일종의 캐시 (자신의 캐시 또는 최대 절전 모드 캐시 중 제어하기 쉬운 것)에 저장하십시오. 따라서 값 비싼 작업은 거의 수행되지 않습니다. 또한 사용자 목록에 페이징을 사용하는 것을 고려하십시오.

  5. ON CASCADE SET NULL을보십시오. 가능하다면 아마도 cascade=ALL + nullable=true이 아닙니다. this thread을 확인하십시오. 엔티티에서 데이터베이스를 생성하지 않으면 데이터베이스에 ON CASCADE SET NULL을 설정하십시오.

그리고 관련 권고 사항 : Hibernate 캐스케이드를 무시하기 때문에 삭제를 위해 HQL을 사용하지 마십시오.

관련 문제