스프링. 상세히 데이터 관리및 조회

spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

 

둘을 모두 properties에 추가해주어야, 사용이 가능

(baeldung가 보기 편한 것 같다) 

 

1. sql쿼리를 출력하고

2. sql 형식을 읽기 쉽게 포멧한다. 

 

현재 있는 DEVELOPERS를 가져오는 것을 만들어 보자.

 

실제 객체 Developers에 직접 접근은 지양해야한다. Dto를 새로 생성하는 것이 유리하다.

유연성, 안전성

 

 

필요한 정보만 들어있는, developer dto (from entity는 entity부터 생성되었다는 뜻! )

 

 

GET METHOD 사용시, 잘 확인됨이 보인다. 

 

이번엔 한개를 따로 상세히 id를 입력받고, 해당 정보를 return하자. 

 

 

이전에 했던 처음 예시가 기억나는가. memberid자체를 url에서 전송하여, 해당 변수를 사용하는 방식이다.

@PathVariable로 해당 값을 가져와서, 변수로 사용할 수 있다. 

 

 

이와 같이, developerdetail이라는 새로운 class를 dto에 생성하였다. 

 

 

물론, memberid로 입력되면, 앞서 적은대로 그 값을 변수로 저장하여 사용하게도 하였다. 

 

 

**굉장히 중요하다**

해당 과정이좀 어려웠는데

Developer repoisotry의 findbyid는 , OPTIONAL<객체> 재너릭 형태로 RETURN하기 때문이다.

이를 해결하기 위해

MAP함수를 활용하여 -> DETAIL CLASS의 FROMENTITY를 적용하였고. 

값이 있을때는 바로 GET을 하고, 없을때는 EXCEPTION을 THROW하는

ORELSETHROW에서, 그렇다면 EXCEPTION을 던졌다. 

 

-- Putmapping -- 수정

 

 

PUTMAPPING으로 (전체의 수정)을 사용했다. PATCH를 사용해도 되었을거 같다는 생각이 들었다. 

 

EDITDEVELOPER를 위한 DTO생성, 3가지의 FIELD만 받아서 사용한다.

 

 

위와같이, FINDBYID로 찾아서 ,그것을 수정해서 바꾸는 형식 구현을 했다.

METHOD를 PUT이 아니라 PATCH로 변경하면, 보기 좋았을거 같다. 

 

DELETE

 

완벽한 삭제가 아닌, 사용자 상태를 '삭제됨'으로 변경하는 형식을 택했다.

이에 따라 FINDALL방식에서, ->삭제되지 않은 DEVELOPERS들만 뺴오는 방식으로 변경또한 진행했다. 

 

 

진행을 하면 할수록, 클론 코딩 전에 내가 코딩을 작성하고, 후에 맞춰봤을때 차이가 줄어듬을 느껴 뿌듯하다. 

 

--힘들었던 오류 -- 

 

JPA REPOSITORY를 상속받은부에서, METHOD를 추가했을때 오류 .

STATUSCODE라는 열거형을 status로 받았는데, 일반 메소드 처럼 이름이 크게 문제가 없는줄 알고 

statuscodeequals로 진행하였고 문제가 발생하였다. 레퍼지토리의 사용시엔 변수명을 주의하자 .

 

 

이와 같이, 또 dto의 request는 statusCode로 되어있었는데, api의 body 부분에서 status, statuscode등의 대 소문자를 맞추지 않아 문제가 발생하였다. 변수명에 항상 주의하는 습관을 들이자.