스프링 DB 1편 - 데이터 접근 핵심 원리 - 섹션1. JDBC 이해

섹션0의 소개란.

밑부터 섹션1 시작

h2를 스프링의 버전에 맞춰서 설치하고 강의대로 사전세팅해서 정상작동하는걸 확인했다.

들어가기 전에 역사를 좀 알아야 왜 이렇게 개판이고 저건 또 뭔지 이해할 수 있다.

DB란 개념은 원래 있었다. 중요한 정보를 보관하는 곳이다.

문제는 각 회사마다 연결해야 하는 방법이 달랐다. 그래서 만약 다른 DB를 쓰게 된다면 코드를 다시 작성해야 했었다. 그래서 나온게 드라이버를 사용하기로 했다.

놀랍게도 각 회사에서 자기가 드라이버용 자바 코드를 짜서 주었다. 그걸 가져다가 사용하기만 하면 되었다.

ㅇㅇ 됨.

참고사항은 JDBC의 등장으로 많은 것이 편리해졌지만, 각각의 데이터베이스마다 SQL, 데이터타입 등의 일부 사용법이 다르다. ANSI SQL이라는 표준이 있어서 어느정도 공통이 있지만, 페이징 같은 심화로 들어가면 두개의 작동방식이 다르다. 결국은 SQL문을 다르게 작성해야 한다. JPA를 사용하면 이렇게 각각 사용해야 하는 부분도 어느정도 해결할 수는 있다.

 

또 기술의 역사도 알아야 된다.

과거에 JDBC 기술이 나왔고 굉장히 오래된 기술이다. 엄청 불편했는데 그래서 얘를 대신 작성해주는 Mapper나 ORM 같은 기술이 등장한다.

 

둘의 차이는 Mapper는 단순히 코드를 직접 작성해주는거라서 SQL만 직접 작성하면 나머지 번거로운 일들을 해결해줘서 쉽다. ORM 기술은 객채를 정의할 때 알아서 찾아서 짜주는 등 SQL 자체를 작성하지 않아도 되서 개발 생산성이 매우 높아지지만 쉬운 기술이 아니라서 실무에서 사용하려면 깊이 있게 학습해야 한다. 강의에선 SQL Mapper의 대표인 MyBatis와 ORM의 대표인 JPA를 학습해본다. 중요한 건 결국 둘 다 JDBC를 사용하는 것이기 때문에 어쨌든 자바 개발자라면 JDBC는 반드시 알아야 한다.

 

다음은 h2를 쓰기 위한 코드 세팅인데 url 같은 부분은 이렇게 작성하기로 한 약속이기 때문에 절때 한 글자도 틀리면 안된단다.

url은 db위치. 여기선 hj2이므로 h2용 db인 test.mv.db 경로다.

규약대로 config 잘 설정하고 연결하면 되는데 안에서 어떤일이 일어나고 있는가

위에서 얘기했던 드라이버를 실제로 하고있는 거다. 여기선 주소값이 jdbc:h2로 시작하니 h2 커넥션이 실행되어 연결된 것. h2 드라이버는 org.h2.jdbc.JdbcConnection이라는 구현체이고 당연히 과거에 있었던 필수 커넥션 코드인 java.sql.Connection을 상속한다.

커넥션을 요청하면 일단 DriverManager.getConntion()에서 자기가 처리 가능한 드라이버 목록들을 쫙 불러온다. 그럼 각자의 드라이버가 url 주소를 보고 자기에게 해당하면 (jdbc:h2, jdbc:mysql 등) 자기가 해당하는 드라이버라고 알려서 해당 드라이버의 실제 커넥션 구현체를 만들어 클라이언트에게 전해준다.

 

 

앞에서 설정한 코드인 getConnection을 통해 DriverManager.getConnection(등록한 url 주소 설정들..)을 통해 실제 connection하고, sql문을 작성해서 실행하는 모습이다. ?, ?는 index를 잘 맞춰서 넣으면 된다. 참고할 점은 execute로 실제 수행하는 건데, PreparedStatement를 써야 SQL injection을 방지한다. 저기 ?에 들어가는 걸 데이터로 쳐주기 때문이라고 함. 주의할 점은 실행 후엔 연결을 끊어주지 않으면 리소스를 계속 잡아먹고 있기 때문에 반드시 close해야 하는데 그래서 finally에서 close를 해준다. 순서에 맞게 connection한 대로 역순으로 close해야 하지만 close 할 게 2개라서 만약 앞에서 close하다가 에러가 나면 뒤의 코드가 실행이 안 되서 close가 안되는 일이 일어난다. 그래서 코드가 좀 복잡해지므로 따로 함수로 빼서 작성하는걸 추천한다.

테스트 해보고 실제 DB를 보면 잘 들어가 있다. 두번 데스트 하면 삭제를 안하고 다시 삽입하려고 하므로 중복 에러가 뜬다.

 

조회도 한번 해보자

아까는 생성하는 거였으므로 executeUpdate였지만 이번엔 조회라서 executeQuery다. 가져오는건 ResultSet으로 정보를 가져오는데 좀 이따가 설명해줄거. close하는 것도 순서를 지키기 위해 아까 만든 함수 쓴다.

설명할게 좀 많은데 일단 테스트에서 만든 멤버 객체 값과 그걸 저장한 뒤에 불러오는 멤버 객체 값이 equal를 통해 같음을 알 수 있다. 사실 둘은 둘 다 각자 new를 통해 만든거라 서로 다른 객체이지만 lombok에서 @Data를 써서 해시값으로 같은지를 점검하는게 isEqualTo라 같은거다.

실제 DB를 순회하면서 조회하는건 ResultSet이다. 포인터같은 거라고 보면 됨.

처음에 rs에다가 executeQuery를 해서 결과를 저렇게 가지고 있는데 계속 next()를 통해서 한줄 한줄 조회하는 것이다. 그래서 실제로는 while를 써서 쭉 점검하지만 나는 데이터가 하나밖에 없기 때문에 그냥 next만 쓴 것이고.

 

이제 편집과 삭제를 해보자. 앞에서 했던 거랑 비슷하다.

 

sql만 잘 적어주면 어차피 executeUpdate() 쓰는건 저장할 때랑 같으니까 걍 하면 된다.

삭제도 비슷함.

 

주의할 점은 테스트할 때 만약 delete 전에 에러가 났다면 db에 남아있고 그럼 다시 실행하면 이미 있다고 에러뜨고 하기 때문에 자기가 한 테스트가 독립적으로 되지 않고 다른 곳에 영향을 준다는 것이다. 이런 문제는 트랜젝션을 적용하면 해결되는 문제다. 참고로 connection하고 실행하고 닫고 connection하고 실행하고 닫고 하기 때문에 로그에서도 여러번 연결하는 걸 볼 수 있다. 이게 좀 낭비라서 다음 섹션에서 커넥션 풀을 소개한다.