til

문제 상황원래는 결제 타입을 결제를 할 때 선택을 하는 방식이었는데, 토스 페이먼츠에서 선택후 반환되는 응답값을 받아서 저장하는 방식으로 변경했습니다. 따라서 기존의 엔티티 클래스를 수정해야 했습니다. 위와 같이 원래의 Enum 타입에서 String 타입으로 변경을 했습니다.org.postgresql.util.PSQLException: ERROR: new row for relation "p_payments" violates check constraint "p_payments_pay_type_check" 그런데 엔티티 클래스 변경 후 위와 같은 에러가 발생했습니다. 이 에러는 PostgreSQL의 p_payments 테이블에 대해 pay_type 컬럼에 정의된 CHECK CONSTRAINT 제약 조건을 위..

개요프로젝트에서 토스 페이먼츠를 사용하여 결제 연동을 진행했습니다. 토스 페이먼츠 SDK를 사용하기 위해 웹페이지가 필요했기 때문에, Thymeleaf를 활용해 간단한 웹 페이지를 구현했습니다. 기존에는 클라이언트에서 HTML을 직접 조회하여 서버에서 정적 HTML 파일을 받아오는 방식을 사용했지만, 사용자 경험을 개선하기 위해 서버 사이드 렌더링으로 전환하기로 했습니다. 이 글에서는 이러한 과정에 대해 정리하고자 합니다. 서버 사이드 렌더링서버 사이드 렌더링(SSR, Server-Side Rendering)은 웹 페이지를 서버에서 미리 렌더링하여 클라이언트(브라우저)로 HTML을 전송하는 방식입니다. 즉, 사용자가 웹 페이지를 요청하면 서버가 필요한 데이터를 조회하고, 그 데이터를 기반으로 완전한 HT..

개요정산 세부 내역 리스트를 가져오는 JPA 코드를 작성하던 중, 성능 문제를 발견했습니다.@Query("SELECT sd FROM SettlementDetail sd WHERE sd.settlement.providerId = :providerId AND sd.settlement.settlementTime = :settlementTime AND sd.isDeleted = false")List findByProviderIdAndSettlementTimeAndIsDeletedFalse(@Param("providerId") Long providerId, @Param("settlementTime") Long settlementTime);// 초기 쿼리select ... from p_settlement_detai..

프로젝트에서 정산 기능을 구현하는 과정에서, 결제 내역을 1대 N 관계로 리스트 형태로 정산 엔티티에 저장하는 방식과, 결제와 정산 간에 중간 테이블을 생성하여 관리하는 방식 중 어느 방법을 선택할지 고민하였습니다. 본 글에서는 이러한 고민과정에서 어떠한 방식을 채택했는지 정리하고자 합니다. 1대 N 사용장점구조가 더 단순합니다.쿼리가 간단할 수 있습니다. (join이 필요없기 때문)추가적인 테이블이 필요 없어 데이터베이스 구조가 간결합니다.단점정산에 포함된 결제 정보가 변경될 경우 데이터 일관성 유지가 어려울 수 있습니다.결제와 정산 간의 관계가 정산 쪽에만 표현되어 있어, 결제 측면에서 조회가 어려울 수 있습니다.대량의 결제 데이터가 있는 경우 성능 문제가 발생할 수 있습니다.중간 테이블 사용장점결제..