행복하개!

특정 엔티티를 영속 상태로 만들 때, 연관된 엔티티도 함께 영속 상태로 만들도 싶을 때 사용한다. 예를 들어, 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장할때 사용한다. 원래 기본은 Child child1 = new Child(); Child child2 = new Child(); Parent parent = new Parent(); parent.addChild(child1); parent.addChild(child2); em.persist(parent); em.persist(child1); em.persist(child2); 이렇게 child1, 2를 다 저장해야한다. 근데, @Entity public class Parent { @Id @GeneratedValue private Long id; p..

참조가 있는 엔티티를 조회할때는 그 참조를 한번에 같이 즉시 조회할지 아니면 사용할때 조회할지에 대한 정의를 내려줘야한다. 즉시 로딩은 엔티티 객체 조회시에 한번에 다 가져오는 것이고, 지연 로딩은 참조의 메서드를 호출 했을 때, 초기화했을 때 그때 불러오는 것이다. @ManyToOne과 @OneToMany의 fetch 전략은 기본이 즉시로딩이다. 이것을 지연로딩으로 바꾸려면 아래 코드와 같다. @Entity public class Member extends BaseEntity { @Id @GeneratedValue @Column(name = "MEMBER_ID") private Long id; @Column(name = "USERNAME") private String username; @ManyToOn..

엔티티 객체를 조회할때는 사용범위를 고려해야한다. 어떤 엔티티 객체가 FK 컬럼으로 다른 엔티티를 참조하고 있다면 이 참조는 즉시 불러와질까, 아니면 어떻게 될까? 앞서 흔하게 사용한 em.find()는 즉시 모든걸 가져온다. 데이터베이스를 통해서 실제 엔티티 객체를 가져온다는 뜻이다. 반면에 EntityManager에는 .getReference()라는 것이 존재하는데, 이는 데이터베이스에서 조회하는 쿼리를 날리지 않고 가짜 엔티티 객체를 가져오는 메서드이다. 간단하게 말하면 가져왔다고 가정은 되어 있지만 실제로 쿼리를 날려서 가져온 것이 아니고 쉽게 말해 null이 들어가 있는 상태이다. 프록시는 실제 클래스를 상속 받아서 만들어진 존재이고 실제 클래스와 겉모양이 같다. 이 프록시는 프록시 객체, 즉 ..

이 어노테이션은 데이터베이스 객체지향과 설계상의 상속관계가 아니고, 그냥 단순하게 공통 매핑 정보가 필요할때 사용한다. 예를 들어 id나 name들은 자주 반복되므로 abstract 클래스를 따로 두고 필요할때 상속해서 사용하는 방법이다. 따라서 정리하자면 상속관계 매핑이 아니고, 엔티티 테이블 매핑도 아니고 그저 부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공하는 방식이다. 당연히 엔티티가 아니기 때문에 조회나 검색이 불가능하다. 주로 등록수정일 등록자나 수정자 같은 전체 엔티티에서 공통으로 적용하는 정보를 모을때 사용한다. 즉, 직접 사용할 일이 없기 때문에 추상 클래스 (abstract) 클래스로 만들어 사용한다. ※ @Entity 클래스는 @Entity나 @MappedSuperclass ..

먼저 객체지향에는 상속이라는 것이 있다. 하지만 관계형 데이터베이스에는 상속이라는 관계가 주어지지 않는다. 하지만 조금 비슷한 것을 보자면, 슈퍼타입과 서브타입이라는 것이 존재한다. 만약 Item이라는 테이블이 존재할때, 키나 DTYPE을 통해서 Album인지 Movie인지 Book인지 등등 어떤 종류인지 구분해내는 것이다. 이런 구현 전략을 위해서 JPA는 3가지의 어노테이션을 제공한다. 1. @Inheritance(strategy = InheritanceType.JOINED) 2. @Inheritance(strategy = InheritanceType.SINGLE_TABLE) 3. @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) 1. 조인 전략 먼..

이 문제는 11053문제 바로 뒤에 나오는 문제이다. 다만 가장 큰 값을 중심으로 왼쪽과 오른쪽으로 값이 작아지는 그 부분 수열의 길이를 알아야하는 문제이다. 처음에 접근 방식은 먼저 가장 긴 증가 부분 수열 방식으로 값을 셋팅해놓고, 큰 값과 그의 인덱스를 저장한 뒤, 그 인덱스부터 가장 긴 감소 부분 수열 방식으로 다시 검색하는 방식으로 진행했었는데, 될 법 한데 자꾸 예외에 부딪히고 코드가 읽기 힘들어졌다. 어찌어찌하면 될 것 같은데 동적프로그래밍의 특성을 제대로 활용하고 싶다고 가정한다면 좋은 접근 법은 아니다. 그렇다면 좋은 접근 법은 무엇이냐? 1. 가장 긴 증가하는 부분 수열을 통해 먼저 카운팅한다. 2. 가장 긴 감소하는 부분 수열을 통해 카운팅을 한다. 3. 합치고 -1한다. 코드를 보자..

정말 알것 같다 싶으면 새로운 유형이 나와버리는 동적프로그래밍이다! 조금씩 익숙해지고는 있지만 자잘한 조건에 난감한 경우가 많다. 이 문제는 LIS문제이다. 이걸 처음 접하면 이게 왜 동적 프로그래밍 문제지? 하고 의문을 가지고 내 식대로 풀다가 망하는 경우가 100% 된다. 망하는 이유는 문제를 정확히 이해하지 못했기 때문이다. 아래는 문제에서 주어진 조건이다. 6 10 20 10 30 20 50 이렇게 보면 그냥 처음부터 max값을 찾아서 10 20 넣고 10은 건너뛰고 30넣고 20은 건너뛰고 50넣고.. 이렇게 하면 될것 같다. 그래서 아래는 그렇게 짠 코드이다. public class BaekJoon_16_11053_2 { public static void main(String[] args) t..

연관관계를 매핑할 때는 1. 다중성과 2. 단방향인지 양방향인지, 양방향일때 3. 연관관계의 주인은 누구로 설정할지가 중요하다. 1. 다중성 여기서 다중성은 4가지가 존재한다. 1) 다대일 N:1 @ManyToOne 2) 일대다 1:N @ OneToMany 3) 일대일 1:1 @OneToOne 4) 다대다 N:M @ManyToMany 2. 단방향, 양방향 앞서 많이 이야기 했지만 테이블은 외래 키 하나만 정해져있어도 어느 방향으로든 데이터를 불러올 수 있다(조인) 방향이라는 개념 자체가 없다. 근데 객체는 아니다. 참조하는 필드가 있는 쪽으로만 방향이 정해져있고 한쪽만 참조하면 단방향, 양쪽이 서로 참조하면 양방향이다. 근데 사실 양방향이라는 용어는 억지로 만들어낸 것이고 단방향 두개라고 생각하면 된다...

먼저.. 인간은 다 비슷한 동물이고 일정 지능이 되면 결국 비슷한 경험을 하게 되는 것 같다. (!!!) 이 2156번 문제도 마찬가지다. ㅋㅋㅋㅋ 2579 문제랑 되게 유사하다. 다만 다른 점은 계단 문제는 규칙 안에서 무조건 하나는 밟게 되어 있는 반면, 이 포도주 문제는 그렇지 않다. 이 문제는 선택하지 않을 수 있다. 이게 무슨 말이냐면 .. 먼저 3가지 측면이 존재한다. 1. 현재 포도주와 직전의 포도주를 마신다. 2. 현재 포도주와 전전 포도주를 마신다. 3. 현재 포도주를 마시지 않고 전의 포도주를 마신 케이스를 선택한다. 그니까 1 2번은 2579 문제에서 풀어서 알겠는데.. 3번은 무슨이야기이냐. 예를 들어, (i=0) 20 (i=1) 50 (i=2) 5

일단 JPA에서 연관관계 매핑은 정말 중요하다. 어찌보면 객체지향과 RDB의 메커니즘 차이를 좁혀주는데 중요한 이론이기도 하다. Member와 Team이라는 테이블이 있다고 가정해보자. 먼저 Member는 하나의 팀만 가질 수 있고, Team은 여러명의 멤버를 가질 수 있다. Team에는 Member의 PK가 외래키로 존재한다. 먼저 RDB의 경우에는 FK(외래키)만 존재해도 어느방향에서도 접근하고 조회할 수 있다. 즉 Team에는 member의 PK가 외래키로 존재하므로 이 외래키를 가지고 두 테이블을 Team에서 조인하든 member에서 조인하던 조인이라는 SQL 쿼리를 만들어서 조회할 수 있다. 하지만 객체의 경우에는 그런 SQL문이 없다. 이걸 억지로 쥐어짜서 가능하게 한다면 member id를 ..