본문 바로가기

분류 전체보기

 (193)
23년 02월 08일 프로젝트 진행을 한지 3일차다. 오늘은 dev브랜치에 머지를 해야하는데 실수로 main브랜치에 머지를 하는 바람에 브랜치에 문제가 생겨 레파지토리를 초기화 하고 새로 생성했다. 코드가 작성된지 얼마 안돼서 다행이었던 것 같다. 그리고 기본 기능 작성후 머지를 했는데, 빌드가 되지않아 오류를 수정했다. @Imbedded를 이용한 profile클래스는 사실 user클래스에 속하는데, 이를 인지하지 못하고 ProfileRepository를 생성해 생긴 문제였다. 팀원과 이에 대해 분업을 시작하기전에 논의를 한 적이 있었는데 제대로 전달되지 않은것 같다. 그리고 이번 프로젝트에는 테스트 코드 작성이 필요하다 생각해 단위 테스트코드를 작성하기로 해서 이에 대해서 팀원들과 논의해서 작성하게 되었다. 그리고 프로젝트..
23년 02월 07일 팀프로젝트를 진행한지 2일차다. 오늘은 대략적인 계획을 세우고 기초적인 구조를 구성해 분업을 시작하였다. 분업은 깃허브 이슈를 통해 작업 내용이 뭔지 커밋을 통해 쉽게 알수 있게 분배하였고, 커밋 양식은 정해진대로 따르기로 하였다. 또한 풀리퀘스트 양식도 pr템플릿에 따라 작성하도록 했고, 본인이 담당한 이슈를 구현완료하면 풀리퀘스트를 통해 이슈를 닫도록 논의했다. 팀원과 @ImbeddedId와 @Imbedded의 차이에 대해서 논의했다. User와 Profile을 나눌지 안나눌지 논의하다가 @Imbedded를 통해 클래스는 나누되, 테이블은 하나로 쓰자고 했는데, 팀원분이 @ImbeddedId와 @Imbedded의 차이를 이해하지못해 설명을 드려야 했다. 오늘은 분업 방식을 결정하고, 본격적으로 분업을..
23년 02월 06일 팀프로젝트 sa를 작성했다. 일단 커밋 규칙과, 코딩 컨벤션, PR템플릿을 정하고 시작했다. 이번에 규칙을 정하면서 pr템플릿이란걸 알게 되었고 pull_request_template.md를 써서 적용해 보았다. 와이어 프레임도 작성했다. api도 작성했는데, 저번에 설계를 해 보았을 때, 처음부터 끝까지 한번에 설계를 하니 설계에 미흡한 부분이 보이고, 상세한 설계가 되지 않아서 일단 기본적인 기능을 완성하고, 리팩토링을 한 후 추가적으로 설계를 해 기능을 붙여나가는 방식으로 프로젝트를 진행하기로 했다. 추가적으로 기능을 완성을 했을때도, 리팩토링을 한 후 다음 기능을 또 추가적으로 완성 해 나갈 생각이다.
23주차 개발일지 jpa심화에 대해서 배우기 시작했다. spring data jpa 이전의 db작성법에 대해서도 배웠는데, spring data jpa가 나 대신 얼마나 많은 일을 해주는지 알게 되었다. 또한 QueryDSL에 대해서도 배웠는데, 아직도 개념이 헷갈려서 강의를 다시 보고 있다. QueryDSL을 사용하는 이유는 4가지가 있는데, 다음과 같다. 문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다. 자동 완성 등 IDE의 도움을 받을 수 있다. 동적인 쿼리 작성이 편리하다. 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있다. QueryDSL과 JPAQueryFactory를 사용하면 직접 jpql을 써서 쿼리를 작성하는 것보다 더 직관적으로 작성할 수 있다..
23년 02월 03일 @DynamicInsert와 @DynamicUpdate에 대해서 배웠다. 두 어노테이션 모두 쿼리를 날릴때 null인 값은 제외하고 쿼리문이 만들어진다. 예를 들어 빌더타입인 User를 작성한다고 할때, User.builder().username("이름").build()를 한다면, @DynamicInsert나 @DynamicUpdate를 선언하지 않았을때의 쿼리는 id,username과 선언해주지 않아 null값인 password까지 가진 쿼리가 나가지만 @DynamicInsert나 @DynamicUpdate를 적용한다면 id,username에 대한 쿼리만 나간다. 당연히 속도에서 차이가 나게 된다. null값이 들어가지 않아도 될 경우에는 선언해주는 것이 좋을 것 같다.
23년 02월 02일 어제에 이어 jpa에 대해서 배웠다. 오늘은 QueryDSL,Auditing,HateOAS등에 대해서 배웠다. 그리고 어제 깜빡하고 기록하지 못한것이 있는데, 일대 다 연관관계를 맺을 때 리스트를 사용하지 말고, 다음처럼 @OneToMany(mappedBy = "thread", cascade = CascadeType.ALL, orphanRemoval = true) private Set comments = new LinkedHashSet(); 링크드해쉬셋을 사용해주는것이 좋다고 한다. QueryDSL은 문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다고 한다. QueryDSL은 QuerydslPredicateExecutor을 레파지토리에 상속시켜 사용할 수 있으며, ..
QueryDSL 기능 QueryDSL의 **Predicate** 인터페이스로 조건문을 여러개를 구성하여 따로 관리할 수 있다. findOne(Predicate), findAll(Predicate) 주로 이 2개 메소드가 사용된다. findOne = Optional 리턴 findAll = List | Page | Iterable | Slice 리턴 Type Safe 기능 조건문 구성시에 사용되는 객체, 필드 조건이 실제 타입과 일치한지 체크해준다. 장점 문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다. 자동 완성 등 IDE의 도움을 받을 수 있다. 동적인 쿼리 작성이 편리하다. 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있다. 원리 QueryDSL 의존성을 추가..
정렬 컬럼값으로 정렬하기 sort class사용 Sort sort1 = Sort.by("name").descending(); // 내림차순 Sort sort2 = Sort.by("password").ascending(); // 오름차순 Sort sortAll = sort1.and(sort2); // 2개이상 다중정렬도 가능하다 Pageable pageable = PageRequest.of(0, 10, sortAll); // pageable 생성시 추가 컬럼이 아닌 값으로 정렬 // 아래와 같이 AS user_password 로 Alias(AS) 를 걸어주면 @Query("SELECT u, u.password AS user_password FROM user u WHERE u.username = ?1") List..
원하는 값만 쿼리로 가져오기 이전에 jpql로 원하는 값만 가져왔었는데, 다음과 같은 방법도 가능하다. @Repository @Transactional public class MyRepositoryImpl implements MyRepository { @Autowired EntityManager entityManager; @Override public List findNameAll() { return entityManager.createQuery("SELECT u.username FROM User AS u", String.class).getResultList(); } }
delete() 메서드 최적화 Spring data jpa의 delete() 메서드는 바로 삭제 쿼리를 날리지 않고 cascade, orphanRemoval 에 의한 자식도 삭제가 누락되지 않도록 영속성 상태인지 확인해서 영속성 컨텍스트에 없다면(!em.contains(entity)) 엔티티를 조회해서 영속성 상태로 바꾼다. 때문에 JpaRepository 의 delete() 는 해당 엔티티를 바로 삭제하지 않고, remove() 메소드를 통해 remove 상태로 바꾼다. 데이터를 영속 상태로 바꾸지 않고 바로 삭제 쿼리를 날리고 싶으면 다음과 같이 써주면 된다. @Repository @Transactional public class MyRepositoryImpl implements MyRepository { @Autowired En..

티스토리툴바