JSJ_Study

문제 상황BaseEntity에서 @Setter를 제거했더니 MapStruct Mapper에서 컴파일 오류가 발생했다.error: Property "id" has no write accessor in User for target name "user.id". ReadStatus toEntity(ReadStatusCreateRequest request);error: Property "id" has no write accessor in Channel for target name "channel.id". ReadStatus toEntity(ReadStatusCreateRequest request);처음엔 단순히 Setter가 없어서 생긴 오류라고 생각했다.ignore = true를 붙이거나 Setter..

1. Dirty Checking이란영속성 컨텍스트는 엔티티를 처음 조회하거나 persist할 때 해당 시점의 스냅샷을 내부에 보관합니다. 트랜잭션 커밋 시점에 flush가 호출되면서 현재 엔티티 상태와 스냅샷을 필드 단위로 비교해, 변경이 있으면 자동으로 UPDATE SQL을 생성합니다. 이것이 Dirty Checking입니다.트랜잭션 커밋 ↓entity manager의 flush 자동 호출 ↓dirty checking (현재 상태 vs 스냅샷 비교) ↓변경 감지 → UPDATE SQL 생성 → DB 전송 ↓JDBC commit (영구 반영)따라서 같은 트랜잭션 내에서 엔티티를 조회하고 수정하면, save() 호출 없이도 트랜잭션 커밋 시 UPDATE가 자동으로 발생합니다.@Tran..

1. JPA vs Spring Data JPA둘을 혼용해서 쓰는 경우가 많지만 역할이 다릅니다.**JPA (Java Persistence API)**는 자바 ORM 표준 명세입니다. 인터페이스만 정의하고, 실제 구현체는 Hibernate가 담당합니다.Spring Data JPA는 JPA 위에 얹힌 추상화 레이어입니다. JpaRepository를 상속하는 것만으로 findById(), save(), delete() 같은 기본 CRUD를 자동으로 제공합니다.Spring Data JPA ↓ JPA (인터페이스) ↓ Hibernate (구현체) ↓ JDBC ↓ DB즉, 우리가 userRepository.save(user)를 호출하면 내부적으로 Hibernat..

협업 시 브랜치 동기화, merge, rebase 어떤 순서로 해야할지 헷갈려 정리해보았다!1. 상황 설정공용 브랜치는 develop나는 feature/login 브랜치에서 작업 중작업하는 동안 팀원이 feature/payment를 develop에 먼저 머지한 상태develop: A --- B --- C --- D (팀원 커밋) \feature/login: X --- Y --- Z (내 커밋)이 상태에서 PR을 올리면 develop과 feature/login 사이에 격차가 생겨 컨플릿이 발생할 수 있습니다.2. 전체 흐름 한눈에 보기① local develop pull ↓② feature rebase develop ↓③ f..

1. Merge Conflict란?Git은 두 브랜치를 병합할 때 변경 사항을 자동으로 합친다.그러나 같은 파일의 같은 라인을 두 브랜치가 서로 다르게 수정했다면, Git은 어느 쪽이 맞는지 판단할 수 없다. 이 상태가 바로 Merge Conflict이다.참고 — Git이 자동으로 합칠 수 있는 경우(서로 다른 파일 수정, 같은 파일의 다른 라인 수정)는 컨플릿 없이 머지됩니다. 컨플릿은 정말로 충돌이 일어났을 때만 발생한다.2. 발생 원인Merge Conflict의 근본 원인은 두 브랜치가 서로의 변경 사항을 모르는 채로 같은 라인을 수정했을 때다. 반대로, 한 브랜치가 다른 브랜치의 커밋 이력을 포함하고 있다면 Git은 충돌 없이 머지할 수 있다.시나리오 1 — 동일 파일, 동일 라인 수정가장 흔한 ..