jy3574 님의 블로그

1. @DynamicInsert 사용1)개요DynamicInsert를 통해 DB의 기본값을 적용하려고 했지만, ItemEntity 테스트 코드를 작성 했을 때 nullable = false의 조건을 확인하는 과정에서 테스트 코드가 정상적으로 동작하지 않는 문제 발생 2)문제상황기본 값 설정을 @PrePersist를 사용해 처리하는 방식으로 수정을 했는데, 테스트 환경에서 DB에 직접적인 기본값 적용 확인이 어려워 DynamicInsert와 중복으로 인하여 여전히 동작하지 않는 문제 발생 DynamicInsert는 SQL INSERT 문을 생성할 때 null 필드를 제외시켜 DB의 기본값을 적용하지만, 코드에서 설정된 값과 충돌하거나 테스트에서 null 처리가 누락이 되면 동작하지 않는 문제 발생 3)해결..

강의 목표Spring Boot 설정부터 JPA 심화까지 학습데이터베이스 연동과 객체 관리의 기본 및 심화 기술 실습프로젝트 세팅 1. Spring Boot를 활용한 프로젝트 생성 및 의존성 관리Spring Initializer를 통해 프로젝트 생성 및 필수 의존성 추가의존성 옵션implementation컴파일 시 의존성 포함외부로 노출 안 됨캡슐화를 유지하며 필요한 라이브러리만 프로젝트에 포함runtimeOnly런타임에만 필요한 의존성 추가ex. H2, 로그 라이브러리testImplementation테스트 전용 의존성 추가테스트 환경에서만 필요한 라이브러리 포함2. 의존성 관리Spring Boot Starterspring-boot-starter-web : REST API, 웹 서버(H2 Console)s..

OrderStatus Enum : 상태 변경 로직1.개요주문 상태(OrderStatus)는 주문 처리 단계를 관리하는 핵심 요소Enum(열거형) 타입으로 구현하여 주문의 진행 상태를 명확하게 정의상태 변경이 순서대로 진행되도록 로직을 설계하고, 중앙에서 관리하여 잘못된 상태 변경의 예외 상황을 방지하고 데이터의 일관성을 유지 2. 왜 이런 설계를 선택했는지?잘못된 상태 변경으로 인해 주문 데이터가 비정상적으로 처리될 가능성이 있고, 순서를 지키지 않아도 통과되는 문제 발생을 없애기 위해 선택canTransitionTo 메서드를 사용하여 상태 전환이 허용된 경우에만 변경 가능3. 상태 변경 로직을 적용 후 예외처리상태 변경의 흐름ORDERED → ACCEPTED: 사장님이 주문을 수락. ACCEPTED →..

1. 코드 구현 전 원활하고 구체적인 의사소통 필요1) 개요프로젝트 진행이 아직 미숙하여 초기에 팀원 간의 충분한 의사소통이 이루어지지 않아 프로젝트 진행 중에 기본 구조 및 코딩 규칙 등이 통일 되지 않았다. 이로 인해 코드 merge 후 여러 문제점 발생 2) 문제 상황기본 구조와 의존성 정의 X문제팀원이 각각 다른 방식으로 프로젝트의 기본 구조를 설계BaseEntity를 포함한 예외 처리 방식, 의존성 추가 등에 대한 사전 합의가 부족결과중복된 의존성이 추가됨 (ex. spring-boot-starter-validation 중복 추가)예외 처리가 전역 예외처리와 Service 계층에서 각각 처리되어 일관성 부족 및 혼란용어 정의 및 타입 불일치문제가게 주인과 관련된 용어를 각각 다르게 정의(Owne..

1. 주제 선택팀원들과 프로젝트 S.A 설계를 완료한 후, 설계가 적합한지 확인하기 위해 튜터님께 피드백을 받았다. 이 과정에서 API 설계의 응답(response) 부분을 성공과 실패로 나눠 상태코드로 표현한 부분에 대해 긍정적인 평가를 받았고, 동시에 에러 상태를 조금 더 구체화하면 좋겠다는 제안과 함께 HTTP 상태코드 설계와 RESTful 여부에 대한 논의가 이루어졌다.피드백 후, 프로젝트 마감 기한이 짧아 팀원들과 깊이 논의할 시간이 충분하지 않아 혼자 고민해보고 정리하고자 이 주제를 선택하게 되었다. 2. 고민한 내용왜 RESTful한 상태 코드를 사용해야 하는가?RESTful하지 않은 설계는 어떤 상황에서 사용하는가?상태코드를 설계할 때 클라이언트를 고려한 방식은 어떤 것인가?만약 RESTf..

피드백 받고 수정예정프로젝트 개요 *프로젝트 목표1. 데이터베이스와 ORM데이터베이스와 스키마를 설계JPA를 이용해 데이터베이스와 연동JPA를 통해 CRUD 작업2. 인가인가 개념을 구현하여 접근 권한을 다르게 설정3. 협업 및 버전 관리Git을 사용해 소스 코드 버전 관리Git branch를 이용해 브랜치 관리 및 원활한 협업Pull Request와 코드 리뷰 과정에 대해 이해*프로젝트 필수 기능 가이드1. 회원가입 / 로그인회원가입사용자 아이디 : 이메일 형식비밀번호Bcrypt로 인코딩 : 암호화를 위한 PasswordEncoder를 직접 만들어 사용대소문자 포함 영문 + 숫자 + 특수문자를 최소 1글자씩 포함비밀번호는 최소 8글자 이상권한회원가입 시 일반 유저 또는 사장님으로 가입권한에 따라 사용할..

Q. 크기가 작은 부분 문자열A.class Solution { public int solution(String t, String p) { int answer = 0; //p의 길이와 같은 부분 문자열을 찾아야하니까 p의 문자열 길이를 pLength로 선언 int pLength = p.length(); //문자열이 아닌 숫자로 비교하여 p가 크거나 같은 경우 횟수+1 long pValue = Long.parseLong(p); //t문자열에서 p와 같은 길이를 찾는거니까 t의 총 길이 - p의 길이까지 부분 문자열 탐색 for(int i=0; i

프로젝트 요약 1. 프로젝트 목적RESTful API 설계 : Spring Boot와 JPA를 사용하여 CRUD API를 설계하고 구현데이터 검증 : Validation을 활용하여 입력값 검증 및 데이터 무결성 보장비즈니스 로직 분리 : 계층별 역할 분리를 통해 유지보수성 향상예외처리 : GlobalExceptionHandler를 통해 예외 처리 방식 학습JPQL 활용 : 데이터 조회 및 요약을 위한 JPQL 사용법 학습2. 프로젝트 구현 단계Lv0 : 프로젝트 설계API 명세서 작성 : postman 사용ERD 작성 SQL 작성Lv1 : 고객(User)과 통화(Currency) 복잡한 연관관계환전 요청 중간 테이블 생성필드 : 고객 고유 식별자, 환전 대상 통화 식별자, 환전 전 금액, 환전 후 금액,..