(TIL) 20220628/ Spring - UUID

🏴󠁩󠁤󠁪󠁷󠁿Facts(한 것) & Findings(배운 것)

---

요즘 과제 테스트와 면접, 코딩테스트 등을 진행하고 있어서 TIL에 조금 소홀했다.

 

다시 열심히 작성해야지!

 

오늘은 과제 테스트를 진행하면서 배운 것에 대해 적어보려 한다.

 

먼저 UUID에 관한 것이다.

 

UUID는 범용 고유 식별자로, domain의 PK 혹은 보조키로 많이 사용되는 자료형이다.

 

아마 기업에서도 많이 사용하고 있는거 같은데, 이 녀석을 스프링, 특히 JPA를 사용할 때 주의해야 할 점이 있다.

 

UUID는 생성되고 DB에 저장될 때 binary(16)으로 저장된다.

 

그렇기 때문에 만약 PK를 BINARY(16) 타입으로 지정하지 않는다면, 그에 맞는 사이즈가 나올 때까지 0을 채워넣는다.

 

이때 문제가 발생하는데, JPA를 통해서 findByID를 실행할 경우, 타입 지정을 하지 않았다면 절대 객체를 찾을 수 없을 것이다.

 

그래서 다음과 같은 설정이 필요하다.

 

package com.sihookang.triple_submission.domain;

import lombok.*;
import org.hibernate.annotations.GenericGenerator;
import org.hibernate.annotations.Type;

import javax.persistence.*;
import java.util.UUID;

@Getter
@AllArgsConstructor
@NoArgsConstructor
@Entity
@Builder
@Table(name = "USER")
public class User {
    @Id
    @GeneratedValue(generator = "UUID")
    @Column(name = "USER_ID", nullable = false, columnDefinition = "BINARY(16)")
    @GenericGenerator(
            name="UUID",
            strategy = "org.hibernate.id.UUIDGenerator"
    )
    private UUID id;
	
    private String name;
}

 

참고로 저기 위에 import문에서 *은 좋지 않은 습관이라고 한다. (나는 임시 클래스라 일단 사용했다.)

 

---

 

JPA 책을 읽으면서 부족했던 연관관계 설정에 대해서 자세하게 살펴볼 기회가 생겼다.

 

항상 FK는 OneToMany에서 Many에 속하고 있기 때문에, FK를 가지고 있지 않은 클래스에서는 반드시 mappedBy를 통해서 자신이 주인이 아님을 알려야 한다.

 

JPA의 연관관계에 대해서는 자세하게 나중에 다루기로 하자.

 

---

오늘도 새삼스럽지만 TDD의 강력함을 많이 느꼈다.

 

굳이 POSTMAN을 사용하지 않아도 내 코드에 문제가 없음을 확인할 수 있고,

 

로직에 문제가 없음을 확인할 수 있었다.

 

만약 그럼에도 불구하고 에러가 발생한다면 DB와 도메인의 설계가 잘못된 것이라...

 

과제에서 테스트 케이스를 작성하면 더욱 좋다고 했는데, 나는 이미 테스트 케이스를 작성하면서 메인 코드를 작성하고 있어서

 

추가적인 부담이 덜긴하다.

 

TDD의 단점이라고 한다면, 아무래도 시간적인 여유가 좀 더 필요할 거 같긴 하다.

 

하지만 테스트를 메인 코드를 작성하고 테스트를 작성한다면, 테스트 코드를 메인코드에 맞게 짤 수도 있기 때문에

 

테스트 코드를 먼저 작성하는게 좋다고 생각한다.

 

 

🏴󠁩󠁤󠁪󠁷󠁿Affirmation(자기선언)

---

• 매일 알고리즘 문제 1문제 이상 풀기 -> 성공

 

🏴󠁩󠁤󠁪󠁷󠁿여담

---