일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 인공지능
- 근구하기
- Perceptron Convergence theorem
- falsePosition
- secant
- 알고리즘대회
- 델타 rule
- 알고리즘
- graphical models
- Numerical optimization
- 이것이 MySQL이다
- 로지스틱 회귀
- undirected graphical model
- 5397번
- 2018
- chapter01
- 자바ORM표준JPA프로그래밍
- bisection
- directed graphical model
- vector미분
- SCPC
- CH01
- Fisher discriminant analysis
- 스터디
- chapter02
- 개발순서
- 선형분류
- 선형판별분석
- MySQL
- 1차예선
- Today
- Total
목록전체 글 (95)
computer_study
1. 컬렉션 JPA 명세에 자바 컬렉션에 대한 언급이 없기에 JPA 구현체에 따라 제공하는 기능이 다를 수 있다. (책에선 하이버네이트 구현체를 기준으로) JPA와 컬렉션 하이버네이트는 엔티티를 영속 상태로 만들 때 컬렉션 필드를 하이버네이트에서 준비한 컬렉션으로 감싼다. ex) ArrayList타입이 하이버네이트가 제공하는 PersistentBag타입으로 변경된다. Collection, List -> PersistentBag으로 변경 ArrayList로 초기화하면 된다. Private Collection collection = new ArrayList(); 엔티티 추가 시 중복된 엔티티가 있는지 비교하지 않고 단순히 저장만 하면 된다. 엔티티를 추가해도 지연 로딩된 컬렉션을 초기화하지 않는다. Set ..
스프링이나 J2EE 컨테이너 환경에서 JPA가 동작하는 동작 방식을 이해한다. 1. 트랜잭션 범위의 영속성 컨텍스트 스프링이나 J2EE컨테이너 환경에서 JPA사용 시 컨테이너가 제공하는 전략을 따라야 한다. 스프링 컨테이너의 기본 전략 트랜잭션 범위의 영속성 컨텍스트 전략을 사용. (트랜잭션 시작 시 영속성 컨텍스트 생성, 트랜잭션 끝나면 영속성 컨텍스트 종료) 스프링에서 서비스 계층에 @Transactional을 선언해서 트랜잭션을 시작 이 때 AOP가 먼저 동작하게 된다. 메소드 종료 시 트랜잭션 커밋하며 종료된다. (이 때 JPA는 영속성 컨텍스트를 플러시하여 변경 내용을 DB에 반영) 예외 발생 시 플러시를 호출하지 않는다. 트랜잭션이 같으면 같은 영속성 컨텍스트 사용 (다르면 다른 영속성 컨텍스..
1. 스프링 데이터 JPA 소개 스프링 프레임워크에서 JPA를 편리하게 사용할 수 있도록 지원하는 프로젝트 CRUD처리를 위한 공통 인터페이스를 제공 인터페이스 작성만 하면 실행 시점에 "스프링 데이터 JPA"가 구현 객체를 동적으로 생성해서 주입해준다. (데이터 접근 계층 구현 없이 인터페이스만 작성해도 개발을 완료할 수 있다.) // JPA의 반복적인 CURD public class MemberRepositroy { @PersistenceContext EntityManager em; public void save(Member member) {...} public Member findOnd(Long id) {...} public List findAll() {...} public Member findBy..
1. 객체지향 쿼리 소개 테이블이 아닌 객체를 대상으로 실행 JPA가 지원하는 기능 JPQL 엔티티 객체를 조회하는 객체지향 쿼리 문법은 SQL과 비슷하나 SQL보다 간결하다 SQL을 추상화 해서 특정 데이터베이스 SQL에 의존하지 않는다. JPQL은 결국 SQL로 변환된다. Criteria 쿼리 Criteria는 JPQL을 생성하는 빌더 클래스 프로그래밍 코드로 JPQL을 작성할 수 있다. 컴파일 시점에 오류를 발견할 수 있다. IDE를 사용하면 코드 자동완성을 지원한다. 동적 쿼리를 작성하기 편하다. 복잡하고 장황하여 불편하고, 코드가 한 눈에 들어오지 않는다는 단점이 있다. 네이티브 SQL SQL을 직접 사용할 수 있는 기능 특정 데이터베이스만 사용하는 기능이나 힌트들을 사용할 때 사용. 데이터베이..
1. 프록시 지연로딩 : 엔티티를 조회할 때 엔티티를 항상 사용하진 않기에, 엔티티가 실제 사용될 때 까지 데이터베이스 조회를 지연하는 방법 이런 지연 로딩을 위해 조회를 지연할 수 있는 가짜 객체가 필요. 이것이 프록시. 1.1 프록시 기초 프록시의 특징 프록시 클래스는 실제 클래스를 상속받아 만들어진다. 사용자 입장은 프록시 객체와 진짜 객체를 구분하지않고 사용할 수 있다. 처음 사용할 떄 한 번만 초기화 된다. (실제 엔티티로 바뀌는 것이 아니라 프록시를 통해 접근할 수 있게 되는 것) 원본 엔티티를 상속받기에 타입 체크 시에 주의해서 사용해야 한다. 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 DB접근이 필요 없기에 실제 엔티티를 반환한다. 준영속 상테의 프록시를 초기화하면 문제가 발생한다. 프록..
1. 상속 관계 매핑 관계형 DB에선 상속이란 개념이 없고 '슈퍼타입 서브타입 관계' 라는 모델링 기법이 상속 개념과 가장 유사하다. 슈퍼타입 서브타입 논리 모델을 실제 물리 모델인 테이블로 구현하는 방법은 3가지 각각의 테이블로 변환(조인전략) 각각을 모두 테이블로 만들고 조회할 때 조인을 사용 장점 테이블이 정규화 된다 외래 키 참조 무결성 제약조건을 활용할 수 있다. 저장공간을 효율적으로 사용한다. 단점 조회할 때 조인이 많이 사용되므로 성능이 저하될 수 있다. 조회 쿼리가 복잡하다. 데이터를 등록할 INSERT SQL을 두 번 실행한다. 특징 JPA 표준 명세는 구분 컬럼을 사용하도록 하지만 하이버네이트를 포함한 몇몇 구현체는 구분 컬럼(@DiscriminatorColumn)없이도 동작한다. * ..
kotest core matchers 범용 obj.shouldBe(other) : 주어진 obj와 other가 모두 같다는 범용 assertion expr.shouldBeTrue() : 표현식이 true인지 확인 expr.shouldBeFalse() : 표현식이 false인지 확인 shouldThrow { block } : 블록이 T Throwable 또는 하위 유형을 throw 하는지 확인 shouldThrowExactly { block } : 블록이 정확히 예외를 throw 하는지 확인 shouldThrowAny { block } : 블록이 모든 유형의 throwable을 throw하는지 확인 shouldThrowMessage(message) { block } : 코드 블록이 주어진 메시지와 함께 모..
엔티티의 연관관계를 매핑할 때 고려해야 할 3가지 다중성(다대일, 일대다, 일대일, 다대다) - 실무에선 보통 다대일과 일대다 관계를 많이 사용한다. 단방향, 양방향 - 객체에서 한 쪽만 참조하는 것이 단방향, 양쪽 서로 참조는 양방향 연관관계의 주인 - 연관관계의 주인만이 외래 키를 변경할 수 있다. 주인이 아닌 곳에 mappedBy([주인 이름]) 을 사용한다. 참고 1. 다대일 다대일 관계의 반대 방향은 항상 일대다 관계 데이터베이스 테이블의 '일', '다' 관계에서 외래 키는 항상 '다' 쪽에 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽 (회원(N)과 팀(1)이 있으면 회원 쪽이 연관관계의 주인) 5장에서 살펴본 내용들이 다대일의 단방향, 양방향 양방향 연관관계는 항상 서로 참조해야 한다...