Hibernate

문제 파악 보통 스프링을 디버깅할 때 SQL 쿼리 로그를 확인하는 선에서 끝나지만, 종종 DataSource나 DDL 이 오류가 발생하거나 예상하지 못한 값이 DB에서 관측될 때는 SQL 쿼리에 포함된 값을 확인할 필요가 있다. 하지만 우리는 Hibernate ORM을 사용하기 때문에 SQL 쿼리에는 바인딩되기 전의 쿼리만 볼 수 있다. 이때 필요한 것이 binding parmater를 추적하는 것인데, 처음 스프링을 배울 때 배운 방법이 작동하지 않았다. (application.properties) logging: level: org: hibernate: type: trace 이전에 진행한 프로젝트에서 똑같이 실행하면 정상적으로 실행된다. 트러블 슈팅 문제 원인 분석 현 프로젝트와 이전 프로젝트 차이라..

디프만 14기에서 참여 중인 프로젝트에서 백엔드 리드 분이 엔티티의 id를 UUID, ULID로 설정한 것을 보았다. 늘 IDENTITY로 설정하여 MySQL이 AUTO_INCREMENT로 관리하도록 위임했기 때문에 기존 방식과 대비해서 어떤 장점이 있길래 사용하는지 알아보았다. AUTO_INCREMENT 전략의 단점 외부에서 예측하기 쉬운 PK PK가 선형적으로 증가하는 정수이기 때문에, 특정 데이터의 PK를 예측하기 쉬워진다. 실제로 request들의 파라미터를 테스트할 때 종종 느꼈던 것이다. 현재 유저의 id 2000이면 1 ~ 1999까지의 id를 가진 유저가 존재할 확률도 높은 것이다. 이는 단순히 노출된다의 문제를 넘어 SQL Injection 공격에도 취약해진다. DB에 의존적인 PK 개발..