Bean에 @NamedNativeQuery의 결과를 저장하고 있으며 쿼리 결과가 고유하지 않으며 빈의 HashCode 및 Equals를 재정의하지 않은 경우가 많습니다. 중복되거나 상관없이 데이터 (쿼리 결과 집합)를 채우기 만하면됩니다.최대 절전 모드에서 @Id 필드로 고유하지 않은 열 지정
고유하지 않은 필드에서 @Id를 지정하는 데 어떤 영향을 미칠 수 있는지 알고 싶습니다.
Bean에 @NamedNativeQuery의 결과를 저장하고 있으며 쿼리 결과가 고유하지 않으며 빈의 HashCode 및 Equals를 재정의하지 않은 경우가 많습니다. 중복되거나 상관없이 데이터 (쿼리 결과 집합)를 채우기 만하면됩니다.최대 절전 모드에서 @Id 필드로 고유하지 않은 열 지정
고유하지 않은 필드에서 @Id를 지정하는 데 어떤 영향을 미칠 수 있는지 알고 싶습니다.
불가능합니다. ID는 고유해야합니다. 귀하의 경우 엔터티가 아닌 pojo가 필요하며 xml을 통해 값을 매핑합니다 (어노테이션으로 가능할 수도 있음). nayive 쿼리에 대한 문서 확인
ID (RDBMS에서 최대 절전 모드까지의 모든 정의)는 고유합니다. 구체적인 개체를 식별하고 구별하는 고유 한 키입니다. 다른 방법으로 그것을하는 것은 끔찍한 반 패턴이며 어떤 상황에서도 결코 그것을 고려해서는 안됩니다.
집합체가 필요하다면 ("복제본과 관계없이") 집합체를 사용하십시오. 구별 및/또는 제한 및/또는 그룹으로 선택하십시오.
예외를 throw하지 않는다고해서 합리적인 것은 아닙니다. 그것은 미래에 당신을 물 것입니다. 오프 핸드 나는 다음과 같은 결과를 초래할 것이라고 생각한다. ID로 엔티티를로드 할 때마다 임의의 복사본을 리턴한다. 그것들의 모음을로드하더라도 무작위로 복사됩니다. 업데이트 할 때마다 임의의 복사본이 업데이트됩니다. 그게 합리적인 주체 신원은 무엇입니까? - 그게 바로 ID의 목적입니다!
그래, 이드는 고유해야한다는 것에 동의하지만 그 속성이 고유하지 않은 경우 어떤 문제가 생길지 알고 싶습니다. 최대 절전 모드가 예외를 던지지 않기 때문에 – dpsdce