들어가면서...이번에 배달 레전드 프로젝트에서는 배달의 민족과 같은 배달 앱을 개발한다.키워드 검색 API를 구현하면서 시도했던 것, 구현한 것을 정리하려고 한다! 먼저 내가 구현하고자 했던 키워드 검색 API의 기능은 특정 키워드로 검색 시해당 키워드가 `가게 이름에 포함된 가게`, 혹은 `해당 키워드가 메뉴 이름에 포함된 가게`들을 조회하는 것이었다. ex) 배달의 민족처럼 가게에 해당 키워드가 포함된 메뉴들이 있다면 뜨도록! 그래서 처음 생각한 방법은 아래와 같다.처음 시도한 방법public Page search(PageRequest pageRequest, String keyword) { // 가게 이름에 해당 키워드가 포함된 가게 가져오기 Page shops = shopRepo.find..
공부/Project
와! 레전드 배달 프로젝트를 진행하면서 `QueryDSL`을 사용할 일이 생겼다.그래서 적용 시키고! 쿼리도 다 짜고! 실행했는데 !!!!!!!!! `no property found for type` 오류가 났다.. 남겨둔 나의 코멘트......... 원인은 기존에 설정해둔 `Repository` 인터페이스 이름 때문 ㅠㅠ우리 팀이 정해둔 컨벤션대로 Repository의 이름을 모두 ~Repo 로 설정했었는데 그것이 원인이었다!!!!!!!!!!!!! `QueryDSL` 사용 시에는 레포지토리 이름을 정직하게 작성하자. 첫 번째처럼 Repo로 작성하면 안되고 풀네임을 작성해야 함!!!!!!!아님 QueryDSL로 작성한 메서드도 JPA로 인식이 돼서 no property 오류가 난다! 이걸로 2시간 ..
이번에는 공동구매 게시물 조회 기능을 구현해볼 것이다.@ManyToOne(fetch = FetchType.LAZY)@JoinColumn(name = "user_id")private User writer; 현재 `Copurchasing` 도메인의 `User` 필드는 `FetchType.LAZY`로 설정 돼 있다. 📌 FetchType`지연 로딩(Lazy Loading)` 연관된 엔티티를 처음 접근할 때까지 로드하지 않고 필요할 때만 데이터베이스에서 데이터를 로드`즉시 로딩(Eager Loading)` 엔티티가 로드될 때 연관된 모든 엔티티를 즉시 로드JPA는 지연 로딩을 위해 `프록시 객체`를 사용한다. 실제 데이터는 필요할 때까지 로드되지 않고, 프록시 객체로 대체된다.`LAZY`는 성능 최적화에 유용..
테스트비즈니스 로직과 제약 사항을 제대로 준수하고 있는지 확인하기 위해 테스트를 ‘필수적으로’ 작성해야 한다.테스트는 시간이 남으면 작성하는 것이 아닌, 우리의 소프트웨어가 제대로 작동하는 것인지 보증해주는 문서와 동일하게 간주하여 꼼꼼하게 작성해야 한다.특히, `예외가 발생하는 테스트`는 반드시 작성해야 한다. 도메인 테스트 작성하기경계값이나 (ex. 0), 실패하는 값을 넣고 예외가 제대로 발생하는지 확인한다. public class Point { private int amount; public Point(int amount) { validateAmount(amount); this.amount = amount; } public void plus(int ..
import lombok.Builder;public class User { private Long id; private String email; private String password; private String nickname; private Point point; // @Builder 어노테이션이 적용된 생성자 @Builder public User(String email, String password, String nickname) { this.email = email; this.password = password; this.nickname = nickname; this.point = new Point()..
유효성 검사를 위한 방법은 상황에 따라 다르며, 일반적으로는 다음과 같은 고려 사항이 있다. 1. 어노테이션을 사용하는 방법장점:코드의 가독성을 높일 수 있다. 필드에 직접 어노테이션을 붙이기 때문에 해당 필드의 제약 조건이 명확하게 드러난다.Hibernate Validator와 같은 라이브러리를 활용하여 기존의 검증 규칙을 재사용할 수 있다.Spring Framework와의 통합이 용이하다. 예를 들어, Spring Boot에서는 Hibernate Validator를 기본으로 제공하므로 설정이 간편함.단점:특정 상황에서는 유효성 검사 로직이 복잡해질 수 있다. 예를 들어, 여러 필드 간의 종속적인 검증이 필요한 경우 어노테이션만으로는 한계가 있을 수 있다.커스텀한 검증 규칙을 정의하고 적용하기 어려운 ..
기존 포인트 합계 VIEW 쿼리문은 다음과 같았다. -- 총 합계 VIEW CREATE OR REPLACE VIEW VIEW_POINT AS SELECT M.CODE, (NVL(R.AMOUNT, 0) + NVL(C.AMOUNT, 0) - NVL(P.AMOUNT, 0) - NVL(W.AMOUNT, 0) + NVL(CH.AMOUNT, 0)) AS POINT FROM MEMBER M FULL OUTER JOIN VIEW_REFUND R ON M.CODE = R.MEMBER_CODE FULL OUTER JOIN VIEW_COMPLETE C ON R.MEMBER_CODE = C.MEMBER_CODE FULL OUTER JOIN VIEW_PAYMENT P ON C.MEMBER_CODE = P.MEMBER_CODE ..
흐아아아아 이게 뭐라고 메인 코드도 이미 짜놨는데 오래 걸렸나 싶다................ 여러가지 방법을 시도해봤는데.. 결국 내가 하려던 방향으로는 해결하지 못해서 아쉽다. 공동구매 게시물 작성 폼 페이지 → 결제 페이지 → 비밀번호 입력 → 결제 완료 페이지 이런 순서로 결제가 진행되는데 폼 페이지에서 결제 페이지로 buypostDTO 객체를 넘기고 또 다시 그 객체를 결제 완료 페이지로 넘겨야 하는데 그 부분에서 막혀버렸다. ↑ 이런 식으로 input hidden 에 buypostDTO 객체를 결제 페이지에 작성하고 그 객체를 jquery 를 통해 get 방식으로 넘겨주는 방법으로 시도해봤는데 get 방식으로는 String 데이터 여러개만 넘길 수 있더라... (key value 형태로) 난..
