Backend/JPA

ORM 개요 OOP 시대에 객체를 RDBMS에 관리하다 보니 SQL 중심적인 개발을 하게 됨으로써 나타나는 문제점들을 해결하기 위해 도입. 객체는 ↔ RDBMS 사이를 매끄럽게 연결하여 SQL 의존성을 덜어내고 OOP 중점적으로 개발을 하는 것이 목표. JPA (Java Persistense Api) 현재 Java 진형의 ORM 표준으로 인터페이스이고 구현체는 Hibernate, EclipseLink, DataNucleus 등 그 중 Hibernate 가 우리가 흔히 쓰는 구현체이다. SpringDataJPA JPA를 한 단계 더 추상화 시켜 개발을 편하게 해주는 Spring에서 제공하는 인터페이스 JPA 구동방식 persistence.xml에 jdbc 관련 정보 ( driver, username, pa..

JPA로 작성되었던 기존 CustomRepository Interface를 상속받은 RepositoryImpl을 QueryDsl 로 복잡한 쿼리를 해결하고 V2로 넘어가는 과정에서 문제가 발생하였다. 기존 OrderRepositoryImpl를 남기고 싶어서 v1,v2 따로 나누기위해 Class 이름 뒤에 v1을 남기고 QueryDsl로 작성한 Repository의 뒤에 v2로 작성하여 돌렸더니 .. 두 시간 삽질을 했다 .. 쿼리가 잘 못 됬는지 확인해보고, 애노테이션도 확인해보고 삽질이란 삽질은 다 했다가 Repository 자체가 문제란걸 깨닫고 CustomRepository 규칙을 다시 보았다. 기본 Impl으로 설정되어있는 접미사가 있어야 있어야 Bean을 만드는 규칙이 있었다. 그리고 리플렉션 ..

엔티티에 대해 ​변경추적 이력을 넣고싶어서 JPA의 Auditing기능을 쓰는 과정에 이상한 점을 찾았다.​ ​@LastModifiedDate만 동작을 안함.. 이게 뭐지..? 하다가 엔티티 하나만 수정해보니 동작은 하는데 문제는 Item들이 전체 세일을 할때 동작을 안함 .. (2~12는 전체할인 기능동작 , 13는 하나만 수정) 아마 전체 할인 기능을 사용할 때 벌크성 쿼리를 날리는 과정에 DB에 바로 때려박아서 변경감지를 못하기 때문에 그런게 아닐까 싶다. 찾아보니 맞는거 같다.. 어쩔수 없이 TimeEntity에 별도의 로직을 추가 한 뒤에 벌크쿼리를 날리기전에 전체 업데이트 한번 한 뒤에 실행하니 수정날짜 바꾸기 동작함 결론 : 벌크성 쿼리는 추적할 생각하지말거나 직접 넣어주는 로직을 짜야함

혼자 스프링 토이프로젝트를 만들면서 JPA를 사용하던도중 엔티티간의 동일성에 대해 궁금증이 생겼다. 우선 , Member 엔티티를 하나 생성을 해서 저장 한 다음 그 ID값으로 find를 실행했을때 출력되는 값은 같음을 확인하였다. 하지만 만약 영속성 컨텍스트를 벗어난다면 ( entityManager를 flush,clear를 시킴 ) 같은 ID같으로 조회해서 가져온 엔티티는 보다시피 불 일치가 나온다. 같은 객체가 아니라는것. 이는 , 같은 엔티티라는 보장을 해 줄때 수정관련 작업에서 변경감지를 쿼리가 나가기전에 1차캐시에서 비교를 먼저 해 주고 만약 변경된 값이 있다면 데이터를 변경시키고 쿼리가 나가지만 영속성을 보장받지 못하면 다른 엔티티이기 때문에 변경감지가 동작하지 않는다. => 같은 ID값으로 ..