관계

[20230722 - 송도 카페콤마] 나는 가끔 요즘말하는 MBTI에서 너무나 극명한 T인 것을 깨닫곤 한다. 친구들과 술 한잔을 기울일 때, 회사에서 동료들과 일을 할 때, 힘든 일이 있어 위로를 받고 싶어 할 때 나는 어떠한 공감과 위로보다는 해결책을 제시하는 편이다. 아니, 편이 아니라 그런 사람이다... 물론 그런 명확한 생각이 좋다고 말하는 사람들도 있지만 나는 30년을 살면서 깨달았다. 많은 사람들은 그런 명확한 생각은 좋다고 말하지만 그런 사람은 싫어한다는 것을.. 그래서 나를 바꾸고 싶었다. 정말 화내고 싶은 상황에서도 참아보고, 직장 동료에게 속으로 내키지도 않는 칭찬을 해보고, 힘든 일이 있는 친구에게 해결책이 아닌 공감과 위로를 해보기도 했다. 하지만 내 마음속 안에서는 정말 전쟁이 ..

복합키 JPA는 영속성 컨텍스트에 엔티티를 보관할 때 엔티티의 식별자를 키로 사용한다. 식별자 필드가 2개 이상이면 별도의 식별자 클래스를 만들어 식별자를 구분해야 한다. JPA는 복합 키를 지원하기 위해 @IdClass와 @EmbeddedId 2가지 방법을 제공한다. @IdClass는 관계형 데이터베이스에 가까운 방법이고, @EmbeddedId는 좀 더 객체 지향에 가까운 방법이다. 복합키 매핑에 예제에서 확인해보자 복합 키: 식별 관계(Identifying Relationship) 매핑 식별 관계는 부모 테이블의 기본 키를 내려받아서 자식 테이블의 기본 키 + 외래 키로 사용하는 관계다. PARENT 테이블의 기본 키 PARENT_ID를 받아서 CHILD 테이블의 기본 키(CHILD_ID) + 외래 ..

@MappedSuperclass를 사용하면 부모 클래스는 테이블과 매핑하지 않고 부모 클래스를 상속받는 자식 클래스에게 매핑 정보만 제공한다. 비유를 하자만 추상 클래스와 비슷한데 @Entity는 실제 테이블과 매핑되지만 @MappedSuperclass는 실제 테이블과 매핑되지 않는다. 단순히 매핑 정보를 상속할 목적으로만 사용된다. 이 클래스를 직접 생성해서 사용할 일은 거의 없으므로 추상 클래스로 만드는 것을 권장한다. @MappedSuperclass public abstract class BaseEntity { @Id @GeneratedValue @Column(name = "ID") private long id; @Column(name = "NAME") private String name; } @E..

아래 자주 쓰이는 기본적인 객체 관계 매핑 어노테이션을 정리해보았다. @JoinColumn 외래 키를 매핑할 때 사용한다. 속성 기능 기본값(Default) name 매핑할 외래 키 이름 필드명 + _ + 참조하는 테이블의 기본 키 컬럼 referencedColumnName 외래 키가 참조하는 대상 테이블의 컬럼명 참조하는 테이블의 기본 키 컬럼명 foreignKye(DDL) 외래 키 졔약조건을 직접 지정할 수 있다. 이 속성은 테이블을 생성할 때만 사용한다. unique nulldable insertable updatable columnDefinition table @Column의 속성과 같다 class Member { @ManyToOne @JoinColumn(name = "team_id", refer..

레지스트리와 쿠버네티스의 관계 쿠버네티스에서도 레지스트리에 이미지를 다운받아 컨테이너를 실행한다. 쿠퍼네티스에서 컨테이너가 동작할 때까지의 흐름을 설명하면 다음과 같다. docker build로 이미지를 빌드한다. docker push로 이미지를 레지스트리에 등록한다. kubectl 커맨드로 매니페스트에 기재한 오브젝트들의 생성을 요청한다. 매니페스트에 기재된 리포지터리로부터 컨테이너의 이미지를 다운로드 한다. 컨테이너를 파드 위에서 가동한다. 이처럼 레지스트리는 쿠버네티스를 사용할 때 반드시 필요한 서비스다. 도커와 쿠버네티스의 연동 쿠버네티스는 도커를 컨테이너의 런타임 환경으로 사용한다. 쿠버네티스를 설치할 때 제일 먼저 도커를 설치해야 하는 이유도 이 때문이다. 도커 데몬 프로세스인 dockerd와..

DIP(역전 의존 원칙)이란? 서비스가 특정 시스템에 의존성을 가지게 되면 서비스 자체만으로 테스트 수행이 어렵고 종속되는 시스템에 따라 서비스의 코드가 지속적으로 변경될 여지가 있다. 저수준 모델이 고수준 모델에 의존하도록 바꾸는 것 변경에 유연하고 테스트가 쉬움 핵심은 의존 관계를 맺을 때 변화하기 쉬운 것에 의존하기보다는, 변화하지 않는 것에 의존 해야한다. 예시 신용카드 클래스를 만든다고 했을때 신용카드에는 여러가지 종류에 은행이 있을것이다. class ShinhanCard { // 신한카드 public void pay() { // 결제 ... } public void pause() { // 카드정지 ... } } class HyunDaiCard { // 현대카드 public void pay() ..