아장아장거리면서 주책부리는 블로그

프록시를 배워서 그래서 뭘 어떻게 하는걸까??? 프록시를 이용해 데이터를 한번에 우다다 DB에서 가져올 필요가 없어진다. 예를 들어, 게임 로그인을 해서 캐릭터를 불러왔다고 해보자. 길드, 친구멤버들의 정보 모두, 장비들, 스킬들, 펫, 아이템들 등등.... 전부를 한번에 불러온다??? (내가봤을 때 로그인할 때 마다 게임 터진다...) 이를 대비해서 지연로딩이 존재한다. 지연로딩을 통해, 연관된 객체들을 전부 불러오는게 아니라 그놈의 프.록.시 로 불러온다. @~~To~~의 외래키 조인을 할 때, (fetch = FetchType.~~)을 통해 즉시로딩과 지연로딩을 정할 수 있다. 이런식으로 만들어진 상태에서 Member를 영속화 시킨 후, 영속성 컨텍스트를 clear시킨다고 해보자. 이 후 Membe..

한짤 요약(이 아닙니다) 프록시를 공부하기 이전에 이전에 영속성 컨텍스트에서 엔티티를 가져와 사용하거나, DB에서 데이터를 가져와 객체로 사용했던 이전의 과정을 기억해보았다. 왜? 프록시는 이 부분에서 엔티티를 사용할 때 마다 데이터를 불러오고, 영속화시키고, 영속성 컨텍스트에서 찾아오고를 줄여주기 위한 녀석이다. Proxy, 영어로 '대리인' 이라는 뜻이 있다. 말 그대로 엔티티에 대한 대리인의 역할을 한다. 대리인, 혹은 복제품, 혹은 가짜라고 다른 글들에서 언급이 되어있다. 그 말대로, 프록시는 원본 객체가 아닌 원본에 대한 복제품을 가져오는 것이다. 가져오는 방법은, EntityManager.find()를 사용하는 것이 아닌, EntityManager.getReference()를 사용하는 것이다...

혹시몰라 나중에 바뀔지도... 이제 상속관계 매핑에 관련된 마지막 어노테이션이다. @MappedSuperclass 근데 사실 이건 상속관계 매핑을 해주는 어노테이션은 아니다. 그저 공통적인 매핑정보를 따로 만들어주기 귀찮기에 만드는 용도이다. 예를 들어, Team과 Member 객체가 동일하게 id, name, createdDate, updatedDate를 가지고 있어야 한다고 가정하자. (왜 그런거 있잖아요 게임할 때 비밀번호 수정 안하면 바꾸라고 알림넣어주고 길드 공지나 게시글 같은거 없으면 좀 쓰라고 길드가 한달동안 한 일이 없다고 닥달하는거!) 그럴 때, 이런 어노테이션을 넣어주면 참 편하다. 코드로 보여주자면, @MappedSuperclass public class BaseEntity { @Id..

상속관계 매핑 자바의 객체, 즉 클래스는 상속을 받을 수 있다. extend를 쓰면 해당 클래스의 메서드나 인스턴스를 쓸 수 있다. 하지만 데이터베이스는 그렇게 되어있지 않다. 말 그대로 관계형 데이터베이스로, 외래키를 이용한 관계들이 얽혀 있어 이를 이용해 객체의 상속을 표현해야 한다. 논리모델을 사진과 같이 구성해, 이를 물리 모델화 시켜야 한다. 물리 모델화 시킨다는 것은 실제 데이터베이스에 들어가는 방식을 설정해야 한다는 것이다. 이 때 크게 3가지 방법이 있는데 조인전력, 단일 테이블 전략, 구현 클래스마다 테이블 전략이 있다. 1. 각각 테이블로 -> 조인 전략 구분자 DTYPE을 메인 테이블에 두고, 구분자를 통해 조인되어 상속을 처리한다. 정규화가 잘 되어있는 편이다. 2. 통합 테이블로 ..

데이터베이스와 JPA에서 사용되는 방식이 정말 비슷하다고 생각되는, 몇 안되는 녀석 중 하나다. 데이터베이스의 다대다 매핑은, 이 매핑을 위한 테이블을 하나 구현한다. 이 테이블에 외래키 두개를 만들어 사용했다. JPA에서도 마찬가지다. 다대다로 매핑할 두 객체 사이에 끼어들어갈 객체를 하나 만든다. 이 객체에 양쪽에서 가운데로 다대일 매핑을 하는 것이다. 예를 들어보자면, @Entity @Table(name = "ORDER_ITEM") public class OrderItem { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "ORDER_ITEM_ID") private Long id; @ManyToOne(fetch = FetchT..

일 대 일, 즉 한명과 다른 한명이 짝을 꼭 맺는다는 뜻이다. 만약 연인이 있는 사람이 다른 사람과 짝을 맺을 수 있지만? (물론 있을 수 있겠지만) 짝을 맺어서는 안되는 것이다. 일대일 매핑은 일종의 연인과 같다. 이 연관관계는 유니크해야한다. 즉, 한 사람이 다른 두 사람과 연관관계에 얽혀서는 안되는 것이다. 일대일 매핑은 외래키에 데이터베이스의 유니크 제약조건이 추가된다. 한쪽이 외래키를 가지면 다른 쪽은 읽기 전용으로 @OneToOne(mappedBy = "매핑 변수명")을 해주어야 한다. 사실 여기까지는 단순하다. 코드로서도, 개념 자체도 쉬운 편이다. 어려운 부분을 이제 건드려 보자면, 연관관계의 주인이다. 일대일 매핑의 조건들은 너무 쉽지만 연관관계의 주인을 누가 할 것이냐가 문제이다. (연..

연관관계의 매핑 방향성, 그리고 주인에 대한 정리가 마무리 되면, 이 매핑을 어떻게 하고 상황에 따라 주인을 어떻게 설정해야 하는지를 알아야 한다. 연관관계의 객체 관계를 보고 이를 판단하게 된다. 연관관계는 흔히 일대일, 일대다, 다대일, 다대다 로 구분된다. 이중에 이번 포스팅은 다대일, 일대다를 이야기해볼 것이다. 데이터베이스를 배울 때에는 일대다에 대해서 배운 적이 없었다. 그저 다대일이라고 이야기했을 뿐이다. JPA에 대해서 알기 전에, 데이터베이스의 다대일은 어떻게 이루어지는지 생각해보아야 한다. 다 쪽에서 외래키를 가지고, 일 쪽의 기본키를 가지게 된다. 이 외래키는 유니크하지 않다. 그래야, 여러 객체가 한 객체의 기본키를 외래키로 가질 수 있다. 다대일의 예시를 보면서 이야기하면 알기 편..

테이블에서는 외래키 하나로 다른 테이블을 자유롭게 이동할 수 있다. 하지만, 테이블은 이게 아닌, 참조한 객체를 매핑해서 외래키처럼 데이터베이스에 적용시킨다. 한 객체가 다른 객체를 참조하고, 이를 @JoinColumn으로 설정한 상태를 단방향 매핑이라고 한다. 참조를 하는 객체는 참조된 객체를 탐색할 수 있다. 하지만, 참조된 객체는 참조한 객체에 대한 정보가 없기 때문에 탐색을 실행할 수 없다. 이럴 때 참조된 객체도 참조한 객체를 탐색하기 위해서 양방향 매핑이라는 것을 한다. public class Order { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "ORDERS_ID") private Long id; @ManyToO..

이전에서도 이야기했듯이, 패러다임에 차이가 있다. 테이블 외래키로 다른 테이블과 연관관계를 맺는다. 객체 참조를 통해 다른 테이블을 불러온다. 이는 엄연한 차이가 존재하는데, 쉽게 생각해보면 테이블을 '길'을 만들고, 객체는 건물의 내부에 다른 건물이 존재하는 것 같다. 테이블의 길을 따라 가면 다른 테이블로 갈 수 있다. 하지만, 건물 안의 건물만 불러와 확인한다면, 그 외부의 건물을 불러올 수 없다. 이를 위해, 객체에도 테이블과 같이 외래키와 비슷한 것을 넣어주어야 한다. @Entity @Table(name = "ORDERS") public class Order { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "ORDERS_..

테이블 매핑, 기본키 매핑, 일반 필드와 컬럼의 매핑까지 완료되었다. 이런 매핑의 설정을 통해 데이터베이스의 스키마를 자동생성을 할 수 있다. 데이터베이스 스키마 자동생성 기능은 JPA이전에 Hibernate에서부터 되었다. 이를 사용하기 위해 내 기준으로는, application.yml(Gradle)나 properties.xml(Maven)에 자동생성을 추가시켜주었다. Maven jpa: hibernate: ddl-auto: update #create update none Gradle 'DDL(데이터 정의어)를 자동으로 사용할 것인가' 라는 뜻으로 직역된다. 사실 말의 의미는 이게 다 라는 생각이 들었다. 실제로 시사하는 바가 무엇이냐 하면, 지금까지 공부한 것을 기준으로는 그게 전부인 것 같다. 하지..