인프런 커뮤니티 질문&답변
작성한 질문수
단건 update 질문
해결된 질문
작성
·
33
·
수정됨
0
안녕하세요.
단건 update관련 질문이 있습니다.
update +연산
update Member m set m.stock = m.stock + 1 where m.id = :id 이런식으로 해야하는 연산은 어떻게 처리하나요?
벌크작업은 아니지만 개수를 증가시킬 때 할당으로 쓰면 덮어씌워질 수 있느니 + 1 로 처리하는 경우도 있는 것으로 아는데, 이런 경우는 영속성 컨텍스트에 반영이 안되는걸로 알고 있습니다.
객체를 기반으로 업데이트 하는 경우 m.stock = n으로 할당이 되어서 이런 경우는 객체지향관점에서 어떻게 처리하고 설계하시는지 궁금합니다.
업데이트 전 조회
업데이트 전에 findOne 조회를 하시던데, 전 업데이트할 때 요청받은값만 덮어쓰면 되고 그게 더 안전할때도 있다고 생각이 듭니다.
이런 경우에는 어떻게 처리하시는지 궁금합니다.
또한, 객체를 기반으로 업데이트하기에는 요청받은 데이터가 객체랑 필드가 정확히 매핑될것 같지 않아서 결국 update문 하나만 요청하는 방식으로 처리해야 할 것 같은데 어떻게 처리하시는지 궁금합니다.
감사합니다.
답변 2
1
안녕하세요. HAHA님
1번 질문의 경우 선택이 필요한데요.
만약 성능과 동시성 관점이 중요한 상황이라면 update a = a + 1을 사용해서 벌크 연산을 사용하고 영속성 컨텍스트를 초기화 하면 됩니다.
2번 질문은 다음을 참고해주세요 🙂
감사합니다.
안녕하세요.
혹시 리스트 데이터와 디테일 데이터에서 필요한 정보가 다를때가 많은데 이런 경우에는 엔티티를 구분해서 선언하시는지 궁금합니다.
아니면 엔티티를 여러 개 선언하지 않고 디테일만 dto를 따로 선언해서 반환하시나요?
이건 엔티티가 아니니 영속성 컨텍스트에서 관리되지 않으므로 복잡해질 이유가 없어서 혹시 이 방법으로 접근하시는지도 궁금합니다.
다른 언어로 개발할때는 디테일과 리스트를 구분해서 개발했었는데, jpa를 사용할때는 영속성 컨텍스트 때문에 고민되어 질문 남깁니다.
실무에서 이런 경우 어떻게 구현하시는지 궁금해서 질문 남깁니다.
감사합니다.
안녕하세요. HAHA님
엔티티는 정규화된 데이터베이스 모델링과 관련이 있습니다. 따라서 엔티티는 하나이고, 대신에 그것을 각 화면에 따라서 표현하는 다양한 방법을 사용해야 합니다.
성능도 크게 중요하지 않고 단순한 상황이라면 엔티티로 리스트와 상세를 모두 표현할 수도 있고, 엔티티 대신에 각 화면에 맞는 리스트용 DTO, 상세용 DTO를 각각 생성해서 반환할 수도 있습니다.
이 부분은 성능과 코딩의 단순함 사이에서의 고민이 필요하기 때문에 각 상황에 맞추어 적용하시면 됩니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. HAHA님.
질문해주신 업데이트와 관련된 여러 가지 상황에 대해 설명드리겠습니다.
- Update +연산:
update Member m set m.stock = m.stock + 1 where m.id = :id와 같이 JPA에서 함수형 변경을 하는 경우, 이는 일반적으로 JPQL의 @Query와 @Modifying 애노테이션을 사용하여 쓸 수 있습니다. 이러한 쿼리는 영속성 컨텍스트에 반영되지 않습니다. 즉, 명시적으로 엔티티 매니저의 clear() 메서드를 호출하여 영속성 컨텍스트를 초기화하지 않으면, 이후에 엔티티를 사용할 때 새로고침하는 동안 영속성 컨텍스트에 있는 데이터와 불일치할 수 있습니다. 따라서, 실무에서는 이런 경우에 의해 변경된 필드를 가능한 한 빨리 엔티티를 통해 읽어오거나 상황에 따라 영속성 컨텍스트를 재설정하는 방법으로 처리합니다.
- 업데이트 전 조회:
업데이트 전에 엔티티를 조회해 오는 과정을 포함하는 패턴은 데이터가 일관되도록 하는 데 도움이 됩니다. 하지만 모든 상황에 필요하지 않습니다. 요청 받은 값만 필요한 경우에는 필요한 필드만 업데이트하고 조회를 생략할 수 있습니다. 이때, 클라이언트가 보낸 데이터가 서버의 엔티티 필드와 정확히 매핑되지 않을 경우 대비하여 DTO(Data Transfer Object) 패턴을 사용할 수 있습니다. 이를 통해 클라이언트와 서버 간의 데이터 구조 차이를 줄이고, 보다 유지보수성이 좋은 코드를 작성할 수 있습니다.
- 객체 기반 업데이트:
객체 지향적인 설계 관점에서 가능한 한 엔티티를 활용하여 비즈니스 로직을 유지하는 것이 좋습니다. 그러나 엔티티와 클라이언트 데이터 구조가 다를 경우에는 앞서 언급한 DTO를 사용하는 것이 좋습니다. 또한, 필요에 따라 직접 쿼리를 사용하여 DB를 업데이트하는 방법도 있지만, 유지보수성과 영속성 컨텍스트 문제를 모두 고려하여 설계해야 합니다.
해당 문제들이 전반적으로 실습 프로젝트나 실제 시스템 구성에 따라 다를 수 있으므로, 다양한 상황에서 테스트를 통해 최적의 솔루션을 찾는 것이 중요합니다.
참고로, @Modifying과 관련된 세부적인 설명은 아래 링크에서 확인하실 수 있습니다:
Spring Data JPA - @Modifying Annotation
답변이 도움이 되셨길 바랍니다.
감사합니다.
바쁘실텐데 답변해주셔서 감사합니다.