1. 멤버변수 중 모든 인스턴스에 공통으로 사용하는 것에는 static을 붙여서 클래스변수로 정의한다. 클래스변수로 정의하게 되면 클래스가 메모리에 올라갈 때 이미 자동적으로 생성되어 Method Area에 저장된다. 2. 클래스 메서드(static메서드)는 인스턴스 변수를 사용할 수 없다. 클래스메서드가 호출되었을 때 인스턴스가 존재하지 않을수도 있기 때문에 클래스 메서드에서 인스턴스 변수의 사용을 금지한다. 반대로 인스턴스 변수나 인스턴스 메서드에서는 클래스멤버들을 사용하는 것이 언제나 가능하다. 클래스 멤버들의 생성이 인스턴스의 생성보다 먼저이기 때문이다. 3. 인스턴스변수를 필요로 하지 않는 경우, static을 붙이는 것이 좋다. 이렇게 하면 클래스가 메모리에 올라갈 때 이미 함께 올라가기 때문..
1. 직접 할당 : 기본 키를 애플리케이션에서 직접 할당 2. 자동 생성 : 대리 키 사용 방식 - IDENTITY : 기본 키 생성을 데이터베이스에 위임(MySQL). 먼저 엔티티를 DB에 저장한 후에 식별자를 조회해서 엔티티의 식별자에 할당. - SEQUENCE : 데이터베이스 시퀀스를 사용해서 기본 키 할당(오라클). persist() 호출시 먼저 DB 시퀀스를 사용해서 식별자를 조회. 그리고 조회한 식별자를 엔티티에 할당 후 엔티티를 영속성 컨텍스트에 저장) -> IDENTITY나 SEQUENCE전략은 사용하는 데이터베이스에 의존 - TABLE : 키 생성 테이블을 사용 -> 모든 데이터베이스에서 사용 가능 키 생성 전략을 사용하려면 persistence.xml에 hibernate.id.new_g..
초기화 : 영속성 컨텍스트의 1차 캐시, 쓰기 지연 SQL저장소가 비워진다. 종료 : 영속성 컨텍스트의 1차 캐시, 쓰기 지연 SQL저장소도 사라진다. 영속성 컨텍스트가 초기화나 종료되면 엔티티는 준영속상태가 된다. 비영속 : 아직 영속성 컨텍스트나 데이터베이스와 전혀 관련이 없는 순수한 객체 상태 준영속 : (원래 관리했지만) 영속성 컨텍스트가 관리하지 않는 상태 준영속 상태로 만들려면 아래와 같은 세 가지 방법이 있다. // 1. 준영속 상태로 em.detach(); // 2. 영속성 컨텍스트 종료 em.close(); // 3. 영속성 컨텍스트 초기화 em.clear(); 준영속 상태의 특징 1. 비영속 상태와 유사하지만 영속상태를 거쳤기 때문에 반드시 식별자 값은 가지고 있다. 2. 지연로딩을 할..
Git 로컬 merge 되돌리기
오늘 바보처럼 로컬에서 작업하고 푸시까지 했는데 사실 잘못된 커밋이었다는 걸 깨달았다... 여러 번 이런 적이 있었고, 그때마다 어찌저찌 돌아가긴 했는데 이번엔 정말 내가 완벽하게 이해한 상태에서 되돌릴 수 있어서 뿌듯했다. 앞으로 같은 문제가 터지면 제대로 해결할 수 있을듯. 그래서 정리해둔다! 우선 정확한 상황을 말해보자면, 1. 원격 : 정상(0) + 잘못된 커밋 1개 올라가 있는 상태 2. 로컬 : 1의 상태(정상(0) + 잘못된 커밋 1개) + 잘못된 merge까지 있는 상태 이랬다. 그래서 로컬이 원격보다 2 커밋 앞에 있던 상태. 그리고 따로 브랜치가 분리된 상태는 아니었다. 단순히 강의들었던 내용 기록목적이라 그냥 main브랜치에서 작업하고 있었다. 그래서 되돌리기 위해 해야 할 일은 1...
지금까지 DB를 이용해서 한 프로젝트는 총 세 번이었다. 세 번의 프로젝트를 하면서 '객체지향이 그렇게 좋다고 노래를 부르면서 왜 객체지향적인 장점을 나는 느낄 수 없는걸까? 객체는 단순히 테이블의 데이터를 전달하는 것 아닌가?'하는 생각이 들었다. ('하나의 객체 안에 멤버변수로 또 다른 객체가 있다면 데이터베이스에서는 어떻게 처리를 해줘야 하나?' 등.) 세 번의 프로젝트 중 두 번은 직접 JDBC API를 사용했고, 한 번은 myBatis를 사용했다. 좀 더 객체지향적으로 애플리케이션을 설계해보고 싶은 욕심을 느꼈고, 마침 그때 를 보고 나와 같은 고민을 한 개발자들이 있고(역시...!) JPA라는 ORM 프레임워크를 알게 되었다. 그래서 JPA를 공부하기 전에 내가 왜 JPA를 배우려고 하는지, ..