ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 스프링 부트 13일차 - Spring Data JPA
    Portfolio/Spring Boot 2019. 5. 26. 17:18
    728x90

    1. 슬라이싱 테스트는 이 레파지토리와 관련된 빈만 등록하여 테스트 하는 것 (당연히 전체 테스트보다 가벼울 듯)


    2. Postgres DB 도커에 띄우기

    docker run -p 5432:5432 -e POSTGRES_PASSWORD=pass -e POSTGRES_USER=jun -e POSTGRES_DB=springboot --name psql_boot -d postgres


    POSTGRES_PASSWORD

    POSTGRES_USER

    POSTGRES_DB


    같은 것은 이미 정의된 환경 변수 이기 때문에 오타 주의해야함.

    값은 내가 하고싶은대로 해도 되고, 상용서버라면 PASSWORD 조심

    --name은 Docker에서 부를 컨테이너의 이름이고, -d는 어떤 이미지를 사용할지 정하는 것임.



    3. JPA 설정시 application.properties에서 다음과 같이 설정해야 DDL이 날아가지 않음


    spring.jpa.hibernate.ddl-auto=validate
    spring.jpa.generate-ddl=false

    추가적으로  validate라는 이름 처럼 기존 스키마에 대한 유효성을 검사해준다. 기존 스키마랑 다르게 컬럼이 새로 생기는 등 문제가 있으면 다음과 같이 에러를 띄워주기도 함.

    Caused by: javax.persistence.PersistenceException: [PersistenceUnit: default] Unable to build Hibernate SessionFactory; nested exception is org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing column [email] in table [account]

    at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:402) ~[spring-orm-5.1.6.RELEASE.jar:5.1.6.RELEASE]

    at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:377) ~[spring-orm-5.1.6.RELEASE.jar:5.1.6.RELEASE]

    at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.afterPropertiesSet(LocalContainerEntityManagerFactoryBean.java:341) ~[spring-orm-5.1.6.RELEASE.jar:5.1.6.RELEASE]

    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1837) ~[spring-beans-5.1.6.RELEASE.jar:5.1.6.RELEASE]

    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1774) ~[spring-beans-5.1.6.RELEASE.jar:5.1.6.RELEASE]

    ... 16 common frames omitted

    Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing column [email] in table [account]

    at org.hibernate.tool.schema.internal.AbstractSchemaValidator.validateTable(AbstractSchemaValidator.java:136) ~[hibernate-core-5.3.9.Final.jar:5.3.9.Final]

    at org.hibernate.tool.schema.internal.GroupedSchemaValidatorImpl.validateTables(GroupedSchemaValidatorImpl.java:42) ~[hibernate-core-5.3.9.Final.jar:5.3.9.Final]

    at org.hibernate.tool.schema.internal.AbstractSchemaValidator.performValidation(AbstractSchemaValidator.java:89) ~[hibernate-core-5.3.9.Final.jar:5.3.9.Final]

    at org.hibernate.tool.schema.internal.AbstractSchemaValidator.doValidation(AbstractSchemaValidator.java:68) ~[hibernate-core-5.3.9.Final.jar:5.3.9.Final]

    at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.performDatabaseAction(SchemaManagementToolCoordinator.java:191) ~[hibernate-core-5.3.9.Final.jar:5.3.9.Final]


    4. 테이블이 Drop되고 Create되는 등의 SQL을 보고 싶으면 다음과 같이 application.properties에 옵션으로 주면됨.

    spring.jpa.show-sql=true


    5. ORM은 단순히 객체와 레코드를 매핑만 하려는게 아님. 

     - 객체 지향 프로그래밍의 장점을 활용하기 좋음.

     - 각종 디자인 패턴

     - 코드 재사용

     - 비즈니스 로직 구현 및 테스트 편함.


    6. ORM에서 객체와 릴레이션의 패러다임 불일치 문제 ** 백기선 선생님 자료에 있는 내용 발췌입니다.

    밀도(Granularity) 문제

    객체

    릴레이션

    다양한 크기의 객체를 만들 수 있음.
    커스텀한 타입 만들기 쉬움.

    테이블

    기본 데이터 타입 (UDT는 비추)


    서브타입(Subtype) 문제

    객체

    릴레이션

    상속 구조 만들기 쉬움.

    다형성.

    테이블 상속이라는게 없음.

    상속 기능을 구현했다 하더라도 표준 기술이 아님.

    다형적인 관계를 표현할 방법이 없음.


    식별성(Identity) 문제

    객체

    릴레이션

    레퍼런스 동일성 (==)

    인스턴스 동일성 (equals() 메소드)

    주키 (primary key)


    관계(Association) 문제

    객체

    릴레이션

    객체 레퍼런스로 관계 표현.

    근본적으로 ‘방향'이 존재 한다.

    다대다 관계를 가질 수 있음

    외래키(foreign key)로 관계 표현.

    ‘방향'이라는 의미가 없음. 그냥 Join으로 아무거나 묶을 수 있음.

    태생적으로 다대다 관계를 못만들고, 조인 테이블 또는 링크 테이블을 사용해서 두개의 1대다 관계로 풀어야 함.


    데이터 네비게이션(Navigation)의 문제

    객체

    릴레이션

    레퍼런스를 이용해서 다른 객체로 이동 가능.

    콜렉션을 순회할 수도 있음.

    하지만 그런 방식은 릴레이션에서 데이터를 조회하는데 있어서 매우 비효율적이다.
    데이터베이스에 요청을 적게 할 수록 성능이 좋다. 따라서 Join을 쓴다.
    하지만, 너무 많이 한번에 가져오려고 해도 문제다.
    그렇다고 lazy loading을 하자니 그것도 문제다. (n+1 select)




Designed by Tistory.