[질문] JPA 사용할 때 update

[익명(223.38)]

트랜잭션 내에서 조회한 엔티티 값 변경되면 flush될 때 변경 감지로 update 쿼리 날라가는데,

값 변경하고 xxRepository.save() 이렇게 명시하는 사람도 있던데

그냥 개인 스타일임?

[코딩계정(quit1004)]

컨벤션마다 다르겠지만 보통 명시해두는게 사이드이펙 적어서 좋아

[백갤러 1(223.38)]

어떤 사이드 이펙트가 생길 수 있는지 여쭤봐도 될까요??

[코딩계정(quit1004)]

음 사이드 이펙이라는게 기술적인 부분도 있고 휴먼에러적인 부분도 있음. 일단 모든 비지니스 로직에 @Transactional을 붙이진 않음. 이말은 즉 지금 당장은 @Transactional이 붙어있더라도, 미래의 누군가 모종의 이유로 없애거나 바뀔수도 있다는거고.. 미래에 추가 요구사항을 반영하며 트랜잭션 범위가 오락가락할 수도 있음. 더티 체킹이라면 이를 모두 생각하며 짜야겠지만, 명시적으로 save()를 하면 그럴 필요가 없음

[코딩계정(quit1004)]

또 중간에 다른 메서드에 엔티티를 넘겨주는 경우에, 해당 메서드 안에서 엔티티가 바뀌었을까?라는 의문을 가져야함. save()를 명시적으로 붙여놨다면 아 안에서 뭔가 바꿨겠구나를 유추할 수도 있겠고.. 거꾸로 엔티티를 넘겨받는 입장에서는 해당 엔티티가 영속 상태일지 detach(번역이 준영속인가?) 상태일지 알 수가 없음. 더티 체킹은 영속 상태에만 통하므로, 변경을 원해서 upateXXX까지만 쳤는데 알고보니 넘겨받은게 detach 상태 였다면 반영이 안되는 경우도 있겠고

[코딩계정(quit1004)]

혼자서 짜는게 아니라 여럿이 짜는 코드라면 뭐 이런 실수가 있겠어? 라는 것도 일어날 수 있어서 최대한 방어적으로 짜두는게 좋음

[코딩계정(quit1004)]

음 예시가 Transactional이랑 save라 그런데, 전반적으로 "안붙여도 돌아는 간다"는 코드나 설정은 웬만하면 이렇게 다 명시해놓고 있음. 미래에 프레임워크 버전올리면서 기본 스펙이 바뀔수도 있거든(jpa가 그럴일은 없겠지만)

[백갤러 1(223.38)]

자세한 설명 감사합니다! 결국 실수 방지를 위함이 크네요

[익명(118.235)]

미개빵즈 답변금지

[백갤러 2(211.241)]

setter 닫아두고 public 메서드로 updateXXX() 이런식으로 하는게 더 직관적일듯