@어노테이션 정리 이어서

>이전 정리 내용

@Component : 얘에 의해 MemoService가 memoService라고 bean으로 등록이 된다.

@Service : service 역할을 하는 bean 클래스라는 것을 명확히 하기 위해 사용 (Component 어노테이션이 포함되어 있는 메서드임)

@RequiredArgsConstructor : lombok을 이용한 방법 --> final을 이용한 필드만을 이용하여 생성자를 자동으로 만들어줌 -> bean을 주입 받아 사용함. --> 하지만 Autowired 방식을 가장 많이 사용함.

@Autowired : 변수 위에 달아주면 private 임에도 불구하고 외부에서 여기에 주입 가능하다. -> 하지만 추천하진 않는다고 나옴(불완전) -> 거의 사용x.
@Autowired : 메서드 위에 달아주면 memoRepository라는 bean을 사용함
(@Autowired 적용 조건: Spring IoC 컨테이너에 의해 관리되는 클래스에서만 가능합니다.)

SpringBoot의 JPA 정리

Spring Data JPA라는 어마무시한 녀석이 있다니... 허허

EntityManagerFactory emf = Persistence.createEntityManagerFactory("memo");
EntityManager em = emf.createEntityManager();

EntityTransaction et = em.getTransaction();
해당 코드를 호출하여 EntityTransaction을 가져와 트랜잭션을 관리

et.begin();
트랜잭션을 시작하는 명령어

em.persist(memo);
EntityManager 사용하여 memo 객체를 영속성 컨텍스트에 저장

et.commit();
트랜잭션의 작업들을 영구적으로 DB에 반영하는 명령어

et.rollback();
오류가 발생했을 때 트랜잭션의 작업을 모두 취소하고, 이전 상태로 되돌리는 명령어

em.find(Memo.class, 1);
호출 시 캐시 저장소에 식별자 값이 1이면서 Memo Entity 타입인 값이 있는지 조회 (내가 찾고자하는 엔터티클래스 타입, 정확한 PK값) -> 캐시에 없으면 DB 조회까지 함.

em.remove(memo); 삭제

em.contains(entity)
Entity 객체가 현재 영속성 컨텍스트에 저장되어 관리되는 상태인지 확인하는 메서드

em.detach(memo);
특정 entity를 준영속 상태로 만들어줌. (영속성 컨텍스트의 어떠한 기능도 사용할 수 없음)

em.clear();
모든 컨텍스트를 모두 초기화, 모든 영속 상태의 엔터티를 준영속으로 만들어버림. 하지만 영속성 컨텍스트의 틀은 유지 됨. -주소값도 동일하더라 (계속해서 영속성 컨텍스트를 이용할 수 있음)

em.close();
clear는 비우고 다시 사용 가능한데 반해, close는 완전히 종료 시켜버림.

em.merge(memo);
준영속 상태에서 다시 영속 상태로 바꾸는 방법. (전달받은 Entity가 영속성 컨텍스트에 없다면 DB 조회 후 수정 or 생성 후 저장)
merge(entity) 메서드는 비영속, 준영속 모두 파라미터로 받을 수 있으며 상황에 따라 ‘저장’을 할 수도 ‘수정’을 할 수도 있음.

em.remove(memo): 삭제하기 위해 조회해온 영속 상태의 Entity를 파라미터로 전달받아 삭제 상태로 전환합니다.

마지막으로 코딩 하고 실행시켜봤더니 안되더라. 아니 왜 오류가..!!
깃 로그를 거슬러가며 체크해봤더니 쿼리문이 제대로 작성되지 않았다는 오류가 떴다.
그럴리가 없는데..? 라고 생각하며 DB를 지웠다가 다시 연결시키니... 짜잔! 말끔하게 해결되었습니다!
설정이 잘못되었던 것도 아니고 다른 점이 없었는데 재연결 시킨 것 만으로 결과가 바뀌다니!

가끔은 내게서 잘못을 찾기 보다는 재부팅이 답이라는 교훈을 얻을 수 있었다.