본문 바로가기

Programming

(138)
Cascade Lazy 지연로딩 시 Proxy 프록시 객체의 null 값 문제 Exception 지연로딩 시 프록시객체의 null값 문제 추가 해당 원인을 나중에 알게되어서 추가한다. lazy loading 한 프록시 객체는 결국 jpa context 안에서 유지되는 것이 있어야 사용 시에 로딩해서 사용할텐데, jpa context 생명주기가 트랜젝션에 따른다. 그래서 트랜잭션을 나와서 controller 단에서 반환하면 에러가 나는 것이다. 해결방법은 이전에 썼던 내용으로 처리하면 될 듯 하다. 지연로딩으로 연관관계가 있는 하위 객체가 프록시객체로 만들어진 경우, 해당 객체의 값은 가져올 수 있다. 하지만 프록시객체 자체를 http response로 넘기게 되면, 내부에서 serialize를 거칠 때 아래와 같은 에러를 볼 수 있다. com.fasterxml.jackson.databind.exc...
CascadeType = removed, JPA hibernate. 관계된 엔티티가 있는 경우에 삭제 시 참조무결성 에러발생 (SQL Error: 23503, SQLState: 23503) 우선 Cascade 의 뜻은, 종속 / 폭포 같은 의미가 있다. 다른 엔티티와 연관관계가 있는 경우, 특히 객체지향 관점에서 상위에 있는 객체의 경우, 삭제 등의 행동 시 하위 관련 엔티티 객체들까지 영속성을 부여해주어야 한다. 영속 컨텍스트에 있다가 flush 까지 되어 DB 업데이트가 완료 되어야 그 이후 에러가 없는 것으로 보인다. CascadeType 으로는 아래와 같이 enum으로 있다. package javax.persistence; /** * Defines the set of cascadable operations that are propagated * to the associated entity. * The value cascade=ALL is equivalent to * cascade={..
JPA hibernate: @OneToOne Lazy Loading, 일대일 매칭에서 지연로딩 시, optional = false 를 주어야 하는 이유 원본: https://stackoverflow.com/questions/17987638/hibernate-one-to-one-lazy-loading-optional-false 이해한 바에 의하면, 지연로딩을 하면 사용 전까지 로딩을 안하기 때문에 assosiation 을 optional true 로 해두면 참조 주소가 있는지 없는지 알 길이 없다. 그래서, optional 을 false 로 해두고 lazy loading을 하더라도 항상 관계가 존재하도록 해주어야 한다. docs를 보면 아래와 같다. javax.persistence.OneToOne public abstract boolean optional() (Optional) Whether the association is optional. If set..
@DataJpaTest 테스트케이스 실행 시 fail, hibernate dialect, AutoConfigureTestDatabase, jdbc sql syntax error JPA 엔티티 클래스 구현 및 테스트케이스 작성 후 리뷰 받은 내용으로 아래 내용이 있었다. @SpringBootTest 어노테이션을 쓰는 것은 테스트 범위가 넓음 @DataJpaTest 어노테이션으로 축소 그래서 그냥 @DataJpaTest 로 변경 했더니, Caused by: org.h2.jdbc.JdbcSQLSyntaxErrorException: Syntax error in SQL statement 위의 에러가 나는데.. 보니까 properties 파일에서 dialect 를 mysql 로 설정한 것이 문법이 안맞는 것 같았음. 그래서 위 두줄을 주석처리하고 돌려보니 된다. 그래서 찾아보니, DataJpaTest 어노테이션 사용 시 AutoConfiguration 되는 것들 중에서, TestDatab..
Git Merge vs Squash and merge(Squash) vs Rebase and merge(Fast forward) 차이점, pull request, 풀리퀘스트 병합 방법 차이점 Merge / Squash and Merge(Squash) / Rebase and Merge(Fast forward) 차이 깃의 커밋 히스토리를 관리하는 관점에서 보면서 사용하면 될 듯 하다. 아래의 그림들에서 개념을 확인 가능하다. 지금부터 아래, 유사하나 좀 더 세부적인 내용 설명 (https://meetup.toast.com/posts/122) 사용 예시 Git Flow 를 따른다고 했을 때, 아래와 같이 정리. develop - feature 브렌치간 머지 : Squash and Merge가 유용합니다. feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브렌치에 추가하여, develop 브렌치에서 독자적으로 관리할 수 있기 때문입니다. 일반적으로 머지..
Git Merge vs Rebase 차이점 Merge 와 Rebase의 차이 merge는 브랜치를 통합하는 개념이고, rebase는 브랜치의 base를 옮긴다는 개념이다. 위 그림에서, merge를 하면 그냥 브랜치를 가져다 다른 부분을 변경 시간에 따라 통합한다. 장점으로는 비파괴적(non-destructive) 이라서 존재하는 브랜치들에 변화를 주지는 않는 것이 있다. 단점으로는 잦은 merge는 git history를 어지럽혀서 가독성을 떨어뜨린다. 위 그림에서, B를 베이스로 시작해서 C와, D-E 브랜치가 생겼을 때, rebase를 해서 D-E의 베이스를 C로 재설정 하는 것을 볼 수 있다. 장점으로는, git history를 깔끔하게 해서 가독성이 좋아진다. 단점으로는, 여럿이 사용하는 public branch에 사용해서는 안된다. 왜..
Git Fetch vs Pull 차이점 Fetch 와 Pull의 차이 fetch 는 remote 브랜치의 최신 정보를 가지고 오면서, 현재 브랜치를 가리키는 HEAD를 이동시키지 않는다. 즉, 최신 정보로 업데이트만 한다. 가지고 와서 병합을 대기. pull 은 remote 브랜치의 최신 정보를 가지고 오면서, 현재 브랜치를 가리키는 HEAD를 맨 앞으로 이동시킨다. 즉, 최신 정보로 업데이트하고 현재 브랜치도 최신 위치로 이동한다. 가지고 와서 병합. fetch를 써서 충돌 방지, 병합 오류를 예방할 수 있다. 각각 실행 후, git log --decorate –all 명령어로 차이를 확인을 해볼 수 있다.
Java의 equals, == 연산자와 String의 비교, JVM의 Heap 과 Constant Pool, Stack 등.. 간략한 Java의 메모리 할당 영역을 살펴본다. 아래 그림의 JVM 윗부분 전체는 Runtime의 Data 영역에 포함된다. (Runtime Data Areas) - Stack 영역 은 함수 호출 시 각각이 Call stack에 쌓이며 함수 내에서의 변수와 포인터 등이 저장되는 영역으로, 함수 종료 시 다같이 해제되며 사라짐. - Heap 영역 은 할당되어 사용되는 것들이 메모리에 쌓이는 영역. 프로그래머가 할당/해제 관리함. C계열에서는 잘 관리하는 것이 필요하고, Java에서는 레퍼런스가 끊어진 할당 객체들이 쌓이면 Garbage Collector가 동작하여 수거하고 메모리 해제를 해준다. - Constant Pool은 Method Area(클래스 파일 정보 저장 위치)에 속하고, 상수 자료형을 저장..