https://spring.io/projects/spring-data-jpa#overview Spring Data JPA Spring Data JPA, part of the larger Spring Data family, makes it easy to easily implement JPA-based (Java Persistence API) repositories. It makes it easier to build Spring-powered applications that use data access technologies. Implementing a data access l spring.io 스프링 JPA에서 지루하게 반복되는 코드를 자동화 해준다. package jpabook2.jpashop2.repo..

OSIV(Open Session In View) JPA에서는 Open In View를 모르면 장애로 이어질 수 있다. ON spring.jpa.open-in-view : true 언제 Jpa는 데이터베이스 커넥션을 가져올까? 기본적으로는 데이터베이스 트랜잭션을 시작할 때 영속성 컨텍스트라는 애가 데이터베이스 커넥션을 가져온다. 언제 db를 돌려주는가? JPA에서는 lazy 로딩 등의 이유로 완전히 모든 로직이 끝날 때까지 데이터베이스 커넥션을 가지고 있다. 이것자체가 큰 장점이다. 단점은 너무 오랜시간동안 데이터베이션 커넥션 리소스를 사용하기 때문에, 실시작 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다. 이것은 결국 장애로 이어진다. 예를 들어서 컨트롤러에서 외부 API를 호출하면 외부 A..
1. 엔티티 조회 방식으로 우선 접근 -> 1. 페치조인으로 쿼리수를 최적화 -> 2. 컬렉션 최적화 -> 1. 페이징 필요 fetchSize 최적화 -> 2. 페이징 필요 x -> 페치 조인 사용 2. 엔티티 조회 방식으로 해결 안되면 DTO 조회 방식 사용 3. DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JDBCTempleate 사용 참고 : 엔티티 조회 방식은 페치 조인이나, fetch_size 같이 코드를 거의 수정하지 않고, 옵션만 약간 변경해서, 다양한 성능 최적화를 시도할 수 있다. 반면에 DTO를 직접 조회하는 방식은 성능을 최적화 하거나 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.

먼저 알아야 할 것이 있다. 패키지 구조를 봤을 때에 같은 order 영역에서도 repository를 나눈 것을 확인 할 수 있다. - entity를 조회하거나 직접 저장하는 경우에는 일반적인 orderRepository를 쓴다. - 화면에 따라 fit하게, 상황에 맞게 쿼리를 정의해야 하는 경우에는 따로 repository(예:OrderQueryRepository)를 만들어 관리한다. 장점 : 화면에 따라 보이는 것과 핵심 비지니스로직을 따로 관리할 수 있다. DTO 직접 조회 @Repository @RequiredArgsConstructor public class OrderQueryRepository { private final EntityManager em; public List findOrders..

@GetMapping("/api/v2/simple-orders") public List orderV2(){ List orders = orderRepository.findAllByString(new OrderSearch()); List result = orders.stream().map(o -> new SimpleOrderDto(o)).collect(Collectors.toList()); return result; } @Data static class SimpleOrderDto{ private Long orderId; private String name; private LocalDateTime orderDate; private OrderStatus orderStatus; private Address add..

1. 엔티티 그대로 노출 @GetMapping("/api/v1/simple-orders") public List orderV1(){ List all = orderRepository.findAllByString(new OrderSearch()); return all; } 엔티티를 그대로 노출할 경우 어떻게 될까? 이렇게 끝도 없는 json을 보게 될 것이다. public class Order { @Id @GeneratedValue @Column(name= "order_id") private Long id; @ManyToOne(fetch = FetchType.LAZY) //order 입장에서는 여러개의 order에 하나의 회원이다. @JoinColumn(name = "member_id") //FK를 지정해준..

V1 @PostMapping("/api/v1/members") public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){ //@RequestBody request로 받은 json 데이터를 객체에 넣어준다. Long id = memberService.join(member); return new CreateMemberResponse(id); } entity package jpabook2.jpashop2.domain; import jakarta.persistence.*; import jakarta.validation.constraints.NotEmpty; import lombok.Getter; import lombok.Setter;..

참고 블로그 : https://www.datoybi.com/http-proxy-middleware/ SOP? 자바스크립트 엔진 표준 스펙의 보안 규칙 중, 하나의 출처(Origin)에서 로드된 자원(문서나 스크립트)이 일치하지 않는 자원과 상호작용 하지 못하도록 요청 발생을 제한하는 정책이 있습니다. 그것이 바로 SOP (Same Origin Policy, 동일 출처 정책)입니다. 즉, http://localhost:8000와 http://localhost:8000/posts는 같은 출처라서 상호작용이 가능한데, http://google.com에서 http://localhost:8000를 호출하면 SOP에 위배됩니다. 그렇다면 동일한 출처의 기준은 무엇일까요? 동일 출처의 기준 http://example..
- Total
- Today
- Yesterday
- 스프링부트
- ArgumentResolver
- JPA
- 백엔드 개발자 공부
- 예외처리
- Java
- reject
- HTTP
- 백엔드 개발자 역량
- 리터럴
- 항해플러스
- 인터셉터
- exception
- jpa api
- react실행
- filter
- 항해99
- 향해99
- Intercepter
- 향해플러스
- rejectValue
- 로그인
- SpringBoot
- React
- 스프링공부
- BindingResult
- 컨트
- 향해플러스백엔드
- hypertexttransferprotocol
- thymleaf
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |