수줍은광돌이

사이드 프로젝트를 진행하는 과정에서 프론트와 백엔드간에 API명세서를 작성해야하는 일이 생겼습니다. 해당 글은 Spring boot 3이상을 사용하는 프로젝트에서 Swagger를 도입하는 경우 어떤 라이브러리가 좋은지 공유하는 시간입니다. Swagger를 제공하는 라이브러리 종류에는 springfox 와 springdoc 가 있습니다. 둘다 써본 결과 제일 괜찮은 것은 springdoc 인거 같아요~ 다만 SpringBoot 3이상은 springdoc를 이용하셔야합니다~ SpringBoot2와 SpringBoot3 둘다 사이드 프로젝트에 참여하면서 해본 결과 확실히 문서 명세서의 Ui 뿐만 아니라 제공하는 서비스에서도 springfox보다 springdoc가 더 좋다는 것을 느꼈습니다. 그러니 sprin..

예약 가능 조건 확인 예약 가능한 일자인지 체크 휴무일 여부 체크 해당 예약가능 날짜 안에 사용시간대 리스트 중 예약 가능 불가능 체크 1,2,3 내용이 포함된 전체적인 틀 코드(캘린더예약 시스템 (1) 에 연장선) // 최종 캘린더 리스트 List resultList = new ArrayList(); //해당 예약상품의 사용시간리스트 조회(날짜별 사용중인 시간대 포함) List x.isCloseDt(date)).findFirst().orElse(null); //stream filter를 통해 조회하는 일자가 존재 하지 않을 경우 휴일이 x if(vo == null){ return false; } return true; } convertCalendarToMap() → 일자에 포함되는 내용 map화 Map..

어쩌다 보니 예약 시스템을 개발하게 되었는데요. 지금 것 참여했던 프로젝트를 보니 쿼리문을 이용해서 달력리스트를 뽑아오는게 대부분이더군요.. 그러다보니 유지보수시 쿼리문이 괘랄해지는?? 문제가 생겨 인수인계 받거나 받는 과정에서 문제가 생기더군요... (어떤 경우는 쿼리가 기본 50줄이 넘어가는...) 그래서 그 경험??을 토대로 쿼리는 단순한 데이터들만 가져오고 서비스단에서 캘린더를 처리하는 방식을 이용하여 유지보수시 코드 가독성에 도움이 되었던 작업내용을 일기처럼 남길까합니다~ 예약 시스템 정보 : 캘린더 달력에서 예약 가능한 날짜 선택 선택시 팝업창과 함께 사용 가능 시간대 체크리스트가 출력 예약가능 상태의 사용시간대를 체크하여 예약 진행 캘린더 생성 방식 종류 달력 테이블을 이용한 달력 형태 생성..

의존성 주입 implementation 'org.springframework.boot:spring-boot-starter-data-jpa' 순수 JPA 기반 리포지토리 @Repository public class TestRepository{ .... } 순수 Spring을 이용할 경우 공통 인터페이스 설정 JavaConfig 설정 ( 만약 Spring boot 일 경우 생략 가능) @Configuration @EnableJpaRepositories public class AppConfig{ ... } @EnableJpaRepositories 는 JPA Repository 공통인터페이스(JpaRepository)를 사용하기 위한 어노테이션이다. @EnableJpaRepositories는 Config 클래스..

EXISTS는 서브 쿼리의 결과가 "한 건이라도 존재하면" true 없으면 false를 리턴한다. EXISTS는 서브 쿼리에 일치하는 결과가 한 건이라도 있으면 쿼리를 더 이상 수행하지 않는다. 예시 TEST 테이블 IDX NAME TYPE 1 TEST1 A 2 TEST2 A 3 TEST3 A TEST_ITEM 테이블 IDX T_IDX NAME 11 1 TEST_ITEM1 12 2 TEST_ITEM2 13 4 TEST_ITEM4 EXISTS 일 경우 SELECT a.idx, a.name FROM test a WHERE a.type = 'A' AND EXIST( SELECT * FROM test_item aa where aa.t_idx = a.idx) 조회를 진행 했을 시 test table 과 test_..

평상시에 최소값을 구하는 쿼리를 작성할때 MIN() 함수를 많이 이용하였다. 그 이유가 편리해서 그렇지 않을까 싶다... 하지만 최근에 이 함수를 이용하여 조회 처리를 하는 과정에서 제대로된 최소값을 가져오지 못하는 현상을 발견하였다. 컬럼들을 대량으로 가져와야하는 상황에서 MIN() 값을 조회하는 처리하는 경우였는데 이상하게 최소값이 제대로 조회 되었다가 안되었다가하는 상황이 발생했다. 해당 이슈에 대해서 명확한 원인을 찾지못해서 좀 아쉬웠지만 그 대신 다른 방식을 구현하여 해당 건에 대하여 해결하였다. 그래서 필요할 경우 해당 MIN() 방식으로는 처리하기 어려울 경우 해당 공유하는 내용을 종종 이용하려고 한다. 예시 table name = "car" SNO A B 1 중형차 2 2 버스 3 )기존 ..