spring boot

[TIL] 240722: PostgreSQL Geometry 매핑 에러

최근에 MySQL에서 PostgreSQL로 데이터베이스를 이관하는 작업을 진행했다. 이 과정에서 geometry 데이터 타입을 사용하는 주소 클래스의 매핑중 오류가 발생했다. 기존에 MySQL에서는 Hibernate Spatial을 사용하여 JPA에서 Geometry 객체를 손쉽게 매핑할 수 있었지만, PostgreSQL에서는 몇 가지 추가 작업이 필요했다. 예시 클래스: AddressEntity AddressEntity는 임베디드 타입으로 주소 정보를 저장하는 데 사용된다. 클래스는 다음과 같은 필드를 포함한다. 여기서 문제가 발생했던 […]

[Spring Webflux:2편] R2DBC

최근 Spring WebFlux와 R2DBC의 조합이 많은 주목을 받고 있다. 이들은 MVC와 JDBC의 전통적인 조합을 넘어서, 현대적인 리액티브 프로그래밍 환경에서 훨씬 우수한 성능을 발휘한다고 알려져 있다. 그렇다면 R2DBC란 정확히 무엇이며, 왜 Spring WebFlux와 잘 맞는 것일까? R2DBC? R2DBC(Reactive Relational Database Connectivity)는 리액티브 프로그래밍을 지원하는 새로운 형태의 데이터베이스 연결 드라이버로, 논블록킹(non-blocking) 방식을 채택하고 있다. Reactive Relational Database […]

[Spring Webflux:1편] 비동기 프로그래밍과 리액터

Thread의 역할 Thread는 프로세스 내에서 실행되는 실행 단위이며, 프로그램 코드를 실행한다. 각 Thread는 동시에 실행될 수 있으며, 멀티태스킹 환경에서 다양한 작업을 동시에 처리할 수 있다. Thread는 할당받은 작업을 수행하고, 작업이 완료되면 결과를 반환하거나 다음 작업을 진행한다. 위 활성상태 정보에서 나타나다시피, 하나의 애플리케이션 내에서 여러 프로세스가 존재할 수 있고, Thread는 프로세스의 메모리와 자원을 공유하면서 독립적인 실행 […]

[Spring Batch:1편] Batch 프로세스 & Spring Batch

1. Batch란 무엇인가? 배치 처리(Batch Processing)는 데이터 처리 작업을 한 번에 모아서 일괄적으로 수행하는 컴퓨팅 기법이다. 초기 컴퓨터 시대에는 입력된 일련의 작업을 순차적으로 처리하기 위해 배치 처리 시스템이 개발되었다. 이 시스템들은 주로 대량의 데이터를 처리하는 데 사용되었으며, 컴퓨터 자원의 효율적 사용을 가능하게 했다. 시간이 지남에 따라 배치 처리 기술은 더욱 발전하여, 금융, 헬스케어, 소매 등 […]

[LUCYTATO] 20240309 스터디 정리: Reactive Programming과 GitFlow

스터디 주제 오늘의 핵심 주제는 Spring Webflux와 Reactive Programming, Git의 운영 방식, AOP(Aspect-Oriented Programming), 그리고 특정 프로젝트 내용의 최적화 방안에 대한 심층 분석이다. Spring WebFlux와 Reactive Streaming 리액티브 프로그래밍은 비동기 데이터 처리와 이벤트 기반 시스템의 효율성을 극대화하는 프로그래밍 패러다임이다. 특히, 리액티브 프로그래밍의 ‘Non-blocking IO’ 특성은 시스템의 처리량과 응답성을 대폭 향상시킨다. PUB/SUB 모델을 기반으로 하는 이 […]

@Transient를 이용한 Mapstruct 매핑 간소화

배경 소상공인 앱을 개발하며 다양한 언어로의 번역 작업은 필수적이었다. 이 과정에서, 특정 테이블의 세 개 필드에 걸쳐 번역이 추가되면서, Entity와 DTO 간의 매핑 작업이 복잡해졌다. 👉다국어 지원을 위한 데이터베이스 설계와 Spring Boot 구현 전략 처음에는 Translation Entity에서 번역 값을 가져오는 방식으로 작업했지만, 해당 값이 없을 경우 대체 언어로 전환하는 추가 작업이 필요했다. 이러한 과정이 비즈니스 […]

Spring Entity 상속 전략 회고

🗣 JPA로 개발하는 대부분에서 조인은 거의 안씁니다. 단순 쿼리만 하거나 별도로 다른 것으로 조회합니다. DB가 물리적으로 나뉘어져 있어서 데이터 소스가 하나가 아니기 때문입니다. 대규모 쇼핑몰로 치면 상품 재고 팀이 있고 회원 팀이 있고 결제 팀이있다면 결제 시 상품 재고, 회원 팀의 API를 통해서 값을 가져와야하는데 분리된 DB에서 JOIN을 할 수 있을까요? 현재 테이블 상태를 살펴보면, […]

Scroll to top