[IDLE-000] 주변 공고 검색 시 중복 쿼리 데이터 방지 #203
Conversation
Walkthrough이 풀 리퀘스트는 GitHub Actions 워크플로우 구성 파일인 Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
idle-batch/src/main/kotlin/com/swm/idle/batch/common/scheduler/CrawlingJobScheduler.kt (1)
16-16: 크롤링 작업 실행 시간이 적절하게 변경되었습니다.실행 시간이 오후 4시 30분에서 4시로 조정된 것이 확인되었습니다.
해당 시간이 선택된 이유를 주석으로 추가하면 좋을 것 같습니다:
+ // 매일 오후 4시에 크롤링 작업을 실행합니다. + // 해당 시간은 [이유를 추가해주세요] 때문에 선택되었습니다. @Scheduled(cron = "0 00 16 * * *")idle-domain/src/main/kotlin/com/swm/idle/domain/jobposting/repository/querydsl/JobPostingSpatialQueryRepository.kt (1)
63-64: 성능 최적화 검토가 필요합니다.
fetchJoin()을 제거하면 N+1 쿼리 문제가 발생할 수 있습니다. 즐겨찾기 데이터를 자주 조회하는 경우, 성능에 영향을 미칠 수 있으므로 다음 사항을 고려해주세요:
- 즐겨찾기 데이터가 항상 필요한 경우
fetchJoin()을 유지- 필요한 경우에만 조회하도록 별도의 쿼리 메소드 추가
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- .github/workflows/dev-server-integrator.yaml (1 hunks)
- idle-batch/src/main/kotlin/com/swm/idle/batch/common/scheduler/CrawlingJobScheduler.kt (1 hunks)
- idle-domain/src/main/kotlin/com/swm/idle/domain/jobposting/repository/querydsl/JobPostingSpatialQueryRepository.kt (1 hunks)
🧰 Additional context used
🔇 Additional comments (3)
idle-batch/src/main/kotlin/com/swm/idle/batch/common/scheduler/CrawlingJobScheduler.kt (1)
Line range hint
16-22: 실행 시간 변경에 따른 영향도를 확인해주세요.크롤링 작업 시간 변경이 다른 시스템이나 프로세스에 영향을 미치지 않는지 확인이 필요합니다.
✅ Verification successful
Let me gather more information about the crawling job configuration and its dependencies.
Let me check the application configuration and batch settings to understand the complete scheduling context.
Based on the analysis of the codebase, I can now provide the final response.
크롤링 작업 시간 변경은 다른 시스템에 영향을 주지 않습니다
크롤링 작업은 다음과 같은 특성을 가지고 있어 시간 변경이 안전합니다:
- CrawlingJobScheduler가 유일한 스케줄러이며, 다른 스케줄링된 작업과의 충돌이 없습니다.
- 배치 작업은 독립적으로 실행되며
application-batch.yml에서 관리됩니다.- 크롤링된 데이터는 API를 통해 비동기적으로 조회되므로, 크롤링 시간 변경이 서비스 로직에 직접적인 영향을 주지 않습니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: 다른 스케줄러나 관련 작업이 있는지 확인합니다. # 스케줄러 관련 파일 검색 echo "=== 스케줄러 설정 검색 ===" rg -l "@Scheduled" # 크롤링 관련 로직 검색 echo "=== 크롤링 관련 로직 검색 ===" rg -l "crawling|crawler"Length of output: 1255
Script:
#!/bin/bash # Check crawling job configuration and dependencies echo "=== Crawling Job Configuration ===" rg -A 10 "class CrawlingJobConfig" echo "=== Crawling Job Dependencies ===" rg -A 5 "crawlingJob()" echo "=== WorknetCrawler Implementation ===" rg -A 10 "class WorknetCrawler" echo "=== API Endpoints Related to Crawling ===" rg -A 5 "@(Get|Post|Put|Delete)Mapping.*crawling" -g "*.kt"Length of output: 34745
Script:
#!/bin/bash # Check application configurations and batch settings echo "=== Application Configuration Files ===" fd -e yml -e yaml -e properties echo "=== Batch Configuration Content ===" cat idle-batch/src/main/resources/application-batch.yml echo "=== Scheduler Related Files ===" rg -l "scheduler|@Scheduled"Length of output: 1471
.github/workflows/dev-server-integrator.yaml (1)
6-6:⚠️ Potential issue개발 워크플로우의 트리거 브랜치 설정을 검토해주세요.
임시 브랜치인
fix/IDLE-000에서 CI 워크플로우를 트리거하도록 변경된 것이 확인됩니다. 이는 일반적인 CI/CD 관행과 다르며 잠재적인 문제를 일으킬 수 있습니다:
- 피처/픽스 브랜치는 일시적이므로 지속적인 통합에 적합하지 않을 수 있습니다.
- CI 워크플로우는 보통 주요 개발 브랜치(
develop,main등)에서 실행됩니다.테스트 목적으로 임시 변경하신 것이라면, 테스트 완료 후
develop브랜치로 되돌리는 것을 권장드립니다.idle-domain/src/main/kotlin/com/swm/idle/domain/jobposting/repository/querydsl/JobPostingSpatialQueryRepository.kt (1)
56-62: 데이터 일관성 검증이 필요합니다.weekday 조인을 left join으로 변경하면 요일 정보가 없는 채용공고도 조회됩니다. 이는 의도된 변경인지 확인이 필요하며, 비즈니스 로직에서 요일 정보가 필수인 경우 문제가 될 수 있습니다.
✅ Verification successful
Let me try a different approach to verify the weekday requirements in the codebase.
Let me try one more search to check the weekday entity and its relationships.
left join으로의 변경은 적절한 수정입니다.
코드베이스 분석 결과, 요일 정보는 다음과 같은 특징을 가지고 있습니다:
- 채용공고 생성 시(
CreateJobPostingRequest)에는 요일 정보가 필수이지만- 채용공고 수정 시(
UpdateJobPostingRequest)에는 요일 정보가 선택사항(List<Weekdays>?)입니다- 응답 DTO들에서도 요일 정보가 nullable로 처리되는 경우가 있습니다
따라서
jobPostingWeekday를 left join으로 변경한 것은 다음과 같은 이유로 적절합니다:
- 수정 API를 통해 요일 정보가 없는 채용공고가 존재할 수 있음
- 요일 정보가 없는 채용공고도 검색 결과에 포함되어야 함
- inner join을 사용할 경우 이러한 채용공고가 누락될 수 있음
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # 요일 정보가 없는 채용공고가 있는지 확인 ast-grep --pattern 'class JobPosting { $$$ @Column(nullable = $_, $$$) weekdays: $$$ $$$ }'Length of output: 101
Script:
#!/bin/bash # Search for JobPosting entity and weekday related fields/annotations rg -A 5 "class JobPosting" # Search for any validation or constraint related to weekdays rg -l "weekday|Weekday" # Check if there are any non-null constraints or validations rg "@NotNull.*weekday|@NotEmpty.*weekday|@NotBlank.*weekday" -iLength of output: 20027
Script:
#!/bin/bash # Check JobPostingWeekday entity and its constraints rg -A 10 "class JobPostingWeekday" # Check if weekdays are required in request/creation rg -A 5 "weekdays.*List<Weekdays>"Length of output: 12658
|
1. 📄 Summary
Summary by CodeRabbit
버그 수정
기능 개선