다음은 사용 사례입니다.3 개의 열에 A, B, C라고 정의 된 고유 색인이 있습니다. 이 값들이 A1, B1, C1이라고 가정합니다. 자바 코드가 A1, B1, C1이라는 새로운 레코드를 추가하고 있지만이 레코드가 추가되기 전에 이전 값을 C1에서 C2로 업데이트합니다. 새로운 레코드를 추가하는 동안 (업데이트 이후), hibernate는 유일한 제약 조건 위반 예외를 던지고있다. 왜 그런지에 대한 이유는 무엇입니까? 위의 모든 명령문은 동일한 트랜잭션 내에서 실행됩니다. 내 가정은 업데이트 전에 발생하므로 예외에 대한 이유입니다.고유 키의 필드 부분을 갱신하는 동안 Hibernate가 고유 제한 조건 위반 예외를 던졌습니다
의견/제안?
업데이트 후에 session.flush()를 사용하십시오.
내 Java 코드는 A1, B1, C1이라는 새로운 레코드를 추가하고 있지만이 레코드가 추가되기 전에는 이전 값이 C1에서 C2로 업데이트됩니다. 새로운 레코드를 추가하는 동안 (업데이트 이후), hibernate는 유일한 제약 조건 위반 예외를 던지고있다. 왜 그런지에 대한 이유는 무엇입니까? 위의 모든 명령문은 동일한 트랜잭션 내에서 실행됩니다. 절전 설계된 동작 방법
, 그것은 save() 시간 (A1, B1, C1)의 값을 삽입 한 다음 (C2로 C1)를 업데이트되며, 이는 A1, B1, C2)를 삽입하지 않을 것이다. Insert and Update in same flush에서 왕을 인용 :
예상 최대 절전 모드 동작은 (우리가 정말 정확 여부 논란이있다!) INSERT 문이 (가) 호출 된 저장 때 설정된 정확하게 데이터를 삽입하는 것입니다. 이것은 사용자에게 조금 더 세분화 된 컨트롤을 제공합니다. 특히 트리거가있는 컨텍스트에서는 더욱 그렇습니다. 그러나 조심하지 않으면 성능이 좋지 않을 수 있습니다.
제안 : (A1, B1, C2)를 직접 삽입하도록 저장을 지연하십시오.
오해의 소지가 있습니다. 질의 순서는 다음과 같다 : a = a1, b = b1, c = c1 테이블 (a1, b1, c1)에 커밋을 삽입한다. 업데이트가 내 가정이되기 전에 어떤 곳에서 hibernate가 삽입을 실행한다. 나는 업데이트 쿼리 후에 session.flush가 해결 될 것이라고 생각한다. – Cshah
@Cshah Ahhhhhh, "새로운"레코드를 업데이트하지 않고 "기존"레코드를 업데이트하고있다. 이 경우 실제로 flush()를 사용하여 업데이트를 강제 실행하십시오. –
트랜잭션 내에서 플러시하는 경우 문제가 발생할 수 있습니까? – Cshah
나는 이것에 결코 문제가 없었다. 나는 그것이 어떻게 작동하는지 또는 어떤 일을하는지 특별히 기억하지 않지만, Hibernate로 Java Persistence에 대한 설명을 찾을 수있다. (내가 이것을 시도한 첫 번째 부분이다.) – Rafael