리소스를 식별하는 통합된 방법URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.URI 안에 URL, URN이 있다. Uniform : 리소스 식별하는 통일된 방식Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없

지정한 IP 주소 (IP Adress)에 데이터를 전달한다.패킷(Packet)이라는 통신 단위로 데이터 전달한다.출발지 IP, 목적지 IP, 기타 정보를 IP 패킷에 담아서 전송한다.출발지 IP 주소와 목적지 IP 주소, 기타 정보를 담은 패킷이 인터넷 노드들을 통해서

개발 환경과 운영 환경에서 어떻게 브랜치를 관리해야 할까? 브랜치는 개발자들이 병렬로 개발하고 실제 운영되는 서비스와 분리하여 개발/테스트 하기 위해 사용된다. 기본 개념 컴파일 : 개발자가 만든 코드를 컴퓨터가 이해할 수 있는 언어로 바꾸는 작업 빌드 : 컴파일

하드웨어 자원을 논리적으로 분리하여 하나의 물리적 시스템에서 여러 개의 가상 환경을 운영할 수 있도록 하는 기술.가상화(Virtualization) 기술은 하드웨어 자원을 논리적으로 분리하여 하나의 물리적 시스템에서 여러 개의 가상 환경을 운영할 수 있도록 하는 기술이

CI/CD 지속적 통합, 지속적 제공/배포 지속적 통합(Continuous Integration) CI(지속적 통합)는 코드 변경 사항을 자주 공유 브랜치(트렁크)에 병합하고, 자동화된 빌드 & 테스트를 실행하여 품질을 유지하는 개발 방식! > CI/CD에서 "CI

트랜잭션과 락 트랜잭션과 격리 수준 트랜잭션은 ASID를 보장해야 한다. 원자성 (Atomicity) : 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공 하거나 실패해야 한다. 일관성 (Consisitency) : 모든 트랜잭션은 일관성 있는 데

JPA 표준 예외는 모두 javax.persistence.PersistenceException의 자식 클래스다. 이 예외 클래스는 RuntimeException의 자식이므로 JPA 예외는 모두 언체크 예외다.여기서 잠깐!언체크 예외가 뭔데??언체크 예외(Unchecke

kafka를 사용하고 있긴 하지만 제대로 된 동작원리나 개념을 모르는 것 같아 살펴보기로 한다.Kafka를 검색하면 나오는 설명으로 크게 두 가지가 있는 것 같다.대용량 데이터 처리를 위해 설계된 분산 메시지 스트리밍 플랫폼이벤트 스트리밍 플랫폼이 설명은 카프카의 기술

JPA는 자바의 컬렉션을 위와 같이 제공하고 다음과 같은 경우에 컬렉션을 사용합니다.@OneToMany, @ManyToOne를 사용하여 일대다나 다대다 엔티티 관계를 매핑할 경우@ElementCollection을 사용해서 값 타입을 하나 이상 보관할 때JPA 구현체마다

스프링이나 J2EE 컨테이너 환경에서 JPA를 사용하면 컨테이너가 트랜잭션과 영속성 컨텍스트를 관리해주므로 쉽게 애플리케이션을 개발할 수 있다. 그러나 정확한 동작방법을 모르면 문제가 발생했을 때 해결하기가 쉽지 않으므로 동작원리를 살펴보자.스프링 컨테이너는 트랜잭션

스프링 데이터 JPA 소개 스프링 데이터 JPA는 스프링 프레임워크에서 JPA를 편리하게 사용할 수 있도록 지원하는 프로젝트다. 반복적인 CRUD 작업을 할 때 해결하기 위해 스프링 프레임 워크에서는 스프링 데이터 JPA를 이용할 수 있다. 공통 CRUD 인터페이스를 제공하고 리포지토리를 개발할 때 인터페이스만 작성하면 실행 시점에 스프링 데이터 JPA가 ...

다양한 이유로 JPQL을 사용할 수 없을 때 JPA는 SQL을 직접 사용할 수 있는 기능을 제공하는데 이것을 네이티브 SQL이라 한다. JPQL을 사용하면 JPA가 SQL을 생성하고 네이티브 SQL은 이 SQL을 개발자가 직접 정의하는 것이다.네이티브 SQL을 사용하면

쿼리를 문자가 아닌 코드로 작성해도, 쉽고 간결하며 그 모양도 쿼리와 비슷하게 개발할 수 있게 해주는 오픈소스 프로젝트.처음에는 HQL(하이버네이트 쿼리언어)을 코드로 작성할 수 있도록 해주는 프로젝트로 시작해서 지금은 JPA, JDO, JDBC, Lucence, Hi

JPA에서는 식별자를 통해 em.find() 메서드로 엔티티를 조회하고, 객체 그래프 탐색을 통해서 연관된 객체를 조회한다. 그러나 특정 조건을 걸어서 조회할 때는 모든 엔티티를 조회하고 검색하는 것은 현실성이 없다. 실제 데이터는 객체가 아닌 데이터베이스에 있기 때문

JPA의 데이터 타입은 크게 엔티티 타입과 값 타입으로 나눌 수 있다.엔티티 타입 : @Entity로 정의하는 객체값 타입 : 자바 기본 타입이나 객체기본 값 타입(basic value type) : 자바 기본 타입, 래퍼 클래스, String임베디드 타입 (embed

객체는 객체그래프 탐색을 통해 연관된 객체를 탐색한다. 그러나 데이터베이스에서는 나뉘어서 저장되어 있기 때문에 연관된 객체를 마음껏 탐색하기에 어려움이 있다. 이에 JPA에서는 프록시를 통해 이 문제를 해결하고 있다.프록시를 사용하면 연관된 객체를 처음부터 데이터베이스

관계형 데이터베이스에는 객체지향 언어에서 다루는 상속이라는 개념이 없다. 대신에 슈퍼타입 서브타입 관계(Super-Type Sub-Type Relationship) 기법이 객체의 상속 개념과 가장 유사하다. ORM에서 상속관계 매핑은 객체의 상속 구조와 데이터베이스의

데이터베이스에서는 항상 다대일관계이면 다쪽에 외래키를 가지고 있어, 다쪽이 연관관계의 주인이다.회원은 Member.team으로 팀 엔티티를 참조할 수 있지만 팀은 회원을 참조하는 필드가 없다. 이런 관계를 회원과 팀 기준으로 다대일 단방향 연관관계라고 한다.양방향은 외

객체는 참조를 통해 관계를 맺고 테이블은 외래키를 통해 관계를 맺는다. 이런 객체의 연관관계와 테이블의 연관관계를 맺는 것이 이 장의 목표이다.다대일(N:1) 단방향 관계를 살펴보자.사진 첨부회원 객체는 Member.team 참조를 통해 연관관계를 맺는다. 이 때, M

엔티티와 테이블을 어떻게 매핑하는지 설계에 해당하는 정적인 부분을 알아보자!JPA를 사용할 때 가장 중요한 부분은 엔티티와 테이블을 정확히 매핑하는 일이다.JPA를 사용해서 테이블과 매핑할 클래스해당 클래스는 필수로 @Entity를 붙여야 한다. 해당 어노테이션이 붙은