Feat/mypage favorite lockers#33
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthrough사용자 즐겨찾기 보관함의 도메인·영속성·인프라·애플리케이션 서비스·REST API·테스트 및 설정이 추가되어 조회, 상태 확인, 추가, 삭제, 순서 재정렬 기능이 구현되었습니다. Changes즐겨찾기 보관함 기능
Sequence DiagramsequenceDiagram
participant User
participant Controller as LockerFavoriteController
participant QueryService as FavoriteLockerQueryService
participant ReaderAdapter as FavoriteLockerReaderAdapter
participant StoreAdapter as FavoriteLockerStoreAdapter
participant Database as Database
User->>Controller: GET /api/v1/me/favorite-lockers?page=0&size=10&lat=37.5&lng=127.0
Controller->>QueryService: getFavorites(userId, page, size, lat, lng)
QueryService->>ReaderAdapter: findByUserId(userId, page, size, lat, lng)
ReaderAdapter->>Database: UserLockerFavoriteRepository.findActiveFavoritesByUserId(...)
Database-->>ReaderAdapter: Page<UserLockerFavoriteEntity>
ReaderAdapter->>Database: LockerReportRepository.findLatestCompletedVoteAtByLockerIdIn(...)
Database-->>ReaderAdapter: List<LockerReportLatestUpdateProjection>
ReaderAdapter->>ReaderAdapter: calculateDistanceMeters(...) & map to FavoriteLocker
ReaderAdapter-->>QueryService: FavoriteLockerPage
QueryService-->>Controller: FavoriteLockerResponse
Controller-->>User: 200 OK
User->>Controller: PATCH /api/v1/me/favorite-lockers/order {lockerIds}
Controller->>StoreAdapter: reorder(userId, lockerIds)
StoreAdapter->>Database: UserLockerFavoriteRepository.findActiveFavoritesByUserIdAndLockerIds(...)
Database-->>StoreAdapter: List<UserLockerFavoriteEntity>
StoreAdapter->>Database: update displayOrder per requested order
Controller-->>User: 200 OK
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested Reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (4)
src/main/java/com/zimdugo/locker/infrastructure/persistence/LockerEntity.java (1)
35-48: ⚡ Quick win전역 소프트 삭제 필터 적용 고려
현재
deleted필드를 추가했지만, 각 쿼리에서 수동으로deleted = false조건을 추가해야 합니다. Hibernate의@SQLRestriction(또는@Wherein older versions)을 사용하면 엔티티 레벨에서 자동으로 필터링되어 실수로 삭제된 데이터를 조회하는 것을 방지할 수 있습니다.♻️ 전역 필터 적용 제안
`@Entity` `@Table`(name = "lockers") +@SQLRestriction("deleted = false") `@Getter` `@NoArgsConstructor`(access = AccessLevel.PROTECTED) public class LockerEntity {이렇게 하면 모든 조회 쿼리에서 자동으로
deleted = false조건이 적용됩니다. 삭제된 레코드를 명시적으로 조회해야 하는 경우에는 네이티브 쿼리나Session.enableFilter()를 사용할 수 있습니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/zimdugo/locker/infrastructure/persistence/LockerEntity.java` around lines 35 - 48, Add a global soft-delete filter to LockerEntity by annotating the entity class (LockerEntity) with Hibernate's `@Where`(clause = "deleted = false") so all queries automatically exclude soft-deleted rows; keep the existing deleted field and markDeleted() method but remove ad-hoc "deleted = false" checks from repositories; also consider adding `@SQLDelete` and `@Loader` or a repository method using Session.enableFilter()/native query when you must explicitly load deleted records.src/main/java/com/zimdugo/locker/infrastructure/persistence/UserLockerFavoriteEntity.java (1)
65-68: 💤 Low value타임존 일관성을 위해 UTC 기준 시각 사용 고려
LocalDateTime.now()는 JVM의 시스템 타임존을 사용합니다. 분산 환경에서 서버 간 시각 불일치가 발생할 수 있으므로,Instant.now()를 사용하거나 데이터베이스의CURRENT_TIMESTAMP를 활용하는 것이 더 안전합니다.♻️ UTC 기준 시각 사용 제안
필드 타입을
Instant로 변경:- `@Column`(nullable = false) - private LocalDateTime createdAt; + `@Column`(nullable = false) + private Instant createdAt;
@PrePersist훅 수정:`@PrePersist` protected void onCreate() { - this.createdAt = LocalDateTime.now(); + this.createdAt = Instant.now(); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/zimdugo/locker/infrastructure/persistence/UserLockerFavoriteEntity.java` around lines 65 - 68, The onCreate `@PrePersist` in UserLockerFavoriteEntity sets createdAt with LocalDateTime.now(), which uses the JVM timezone; change the createdAt field to an Instant (or offset-aware type) and set it using Instant.now() in the onCreate method (or switch to database-side CURRENT_TIMESTAMP by marking the column default), ensuring consistent UTC timestamps; update any getters/setters/DTO mappings that reference createdAt to handle Instant accordingly.src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerProperties.java (1)
10-14: ⚡ Quick win좌표 값 범위 검증 추가 권장
latitude와longitude필드에 유효 범위 검증이 없습니다. 잘못된 설정 값은 거리 계산 시 런타임 오류나 부정확한 결과를 초래할 수 있습니다.✅ 검증 애너테이션 추가 제안
+import jakarta.validation.constraints.DecimalMax; +import jakarta.validation.constraints.DecimalMin; + `@ConfigurationProperties`(prefix = "locker.favorite") public record FavoriteLockerProperties( DefaultOrigin defaultOrigin ) { public record DefaultOrigin( + `@DecimalMin`(value = "-90.0", message = "위도는 -90 이상이어야 합니다") + `@DecimalMax`(value = "90.0", message = "위도는 90 이하여야 합니다") double latitude, + `@DecimalMin`(value = "-180.0", message = "경도는 -180 이상이어야 합니다") + `@DecimalMax`(value = "180.0", message = "경도는 180 이하여야 합니다") double longitude ) { } }
@ConfigurationPropertiesBinding과 함께 사용하면 애플리케이션 시작 시 설정 값을 검증할 수 있습니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerProperties.java` around lines 10 - 14, Add range validation to the DefaultOrigin record by annotating its latitude and longitude components with appropriate Bean Validation constraints (latitude between -90 and 90, longitude between -180 and 180) and ensure the enclosing configuration properties class is validated at startup (e.g., annotate the configuration properties class with `@Validated` or use `@ConfigurationPropertiesBinding` as appropriate) so invalid settings fail fast; update DefaultOrigin (the record) to use `@DecimalMin/`@DecimalMax or equivalent annotations on the latitude and longitude parameters and enable validation on the containing properties bean.src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerStoreAdapter.java (1)
50-78: ⚡ Quick win예외 타입을 코드베이스 규약(
BusinessException+ErrorCode)에 맞춰 통일하는 것을 권장합니다.같은 클래스 내
add()는 도메인 오류에 대해BusinessException을 던지는 반면,reorder()는IllegalArgumentException을 직접 던지고 있어 예외 처리/응답 매핑 계층에서 일관성 있게 다루기 어렵습니다. 클라이언트 입력 검증 실패에 해당하므로 적절한ErrorCode를 정의해BusinessException으로 일원화하는 편이 글로벌 예외 핸들러와 HTTP 응답 코드 매핑에 유리합니다.♻️ 제안 예시
- if (favoriteCount != lockerIds.size()) { - throw new IllegalArgumentException("Favorite locker order request must include all favorites."); - } + if (favoriteCount != lockerIds.size()) { + throw new BusinessException(ErrorCode.INVALID_FAVORITE_ORDER_REQUEST); + } ... - if (favorites.size() != lockerIds.size()) { - throw new IllegalArgumentException("Favorite locker order request contains unknown locker ids."); - } + if (favorites.size() != lockerIds.size()) { + throw new BusinessException(ErrorCode.INVALID_FAVORITE_ORDER_REQUEST); + } ... - if (favorite == null) { - throw new IllegalArgumentException("Favorite locker order request contains duplicate locker ids."); - } + if (favorite == null) { + throw new BusinessException(ErrorCode.INVALID_FAVORITE_ORDER_REQUEST); + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerStoreAdapter.java` around lines 50 - 78, The reorder method in FavoriteLockerStoreAdapter currently throws IllegalArgumentException for various validation failures; change these to throw BusinessException with a specific ErrorCode (e.g., INVALID_FAVORITE_ORDER or a new code that fits your error catalog) so it matches the add() behavior; replace each IllegalArgumentException in reorder(...) with new BusinessException(ErrorCode.YOUR_CHOICE, "descriptive message") (for duplicate/unknown/count-mismatch cases), and ensure any callers/tests and the global exception mapping expect that ErrorCode.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/main/java/com/zimdugo/locker/entrypoint/FavoriteLockerOrderUpdateRequest.java`:
- Around line 6-9: FavoriteLockerOrderUpdateRequest currently uses `@NotEmpty` on
lockerIds but does not validate individual elements; update the record
declaration to validate each list element by annotating the generic type: change
the parameter to List<@NotNull `@Positive` Long> lockerIds and add the imports
jakarta.validation.constraints.NotNull and
jakarta.validation.constraints.Positive so each element is checked for non-null
and positivity while retaining the existing `@NotEmpty` on the list itself.
In `@src/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteApi.java`:
- Around line 118-124: The removeFavoriteLocker endpoint in LockerFavoriteApi
accepts a path variable lockerId without validation allowing zero or negative
values; add a Bean Validation annotation such as `@Positive` or `@Min`(1) to the
`@PathVariable` parameter (lockerId) and ensure the controller interface or its
implementation is annotated with `@Validated` so the constraint is enforced at
runtime; update the method signature for removeFavoriteLocker to include the
validation annotation on lockerId and confirm the class LockerFavoriteApi (or
the implementing controller) has `@Validated`.
- Around line 70-76: The getFavoriteLockerStatus API method accepts a path
variable lockerId without validation; add a Jakarta Bean Validation constraint
(e.g., annotate the lockerId parameter with `@Positive`) and import
jakarta.validation.constraints.Positive so negative or zero IDs are rejected at
the API layer; update the method signature for getFavoriteLockerStatus to
include the annotation on the `@PathVariable` Long lockerId and ensure the class
is set up to trigger validation (e.g., controller is validated by the
framework).
- Around line 102-108: The lockerId path variable in
LockerFavoriteApi.addFavoriteLocker lacks validation and can receive 0 or
negative values; add a validation annotation (e.g., `@Min`(1) or `@Positive`) to the
`@PathVariable` Long lockerId parameter and ensure the controller interface/class
is annotated with `@Validated` so Bean Validation runs (also add the corresponding
javax.validation import). This enforces lockerId > 0 for the addFavoriteLocker
endpoint.
In `@src/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteController.java`:
- Around line 84-90: extractUserId에서 authentication.getName()이 Long으로 파싱되지 않을 경우
NumberFormatException이 발생하므로 Long.valueOf(...) 호출을 try-catch로 감싸고
NumberFormatException을 잡아 적절한 BusinessException으로 변환해 던지세요 (예: 새로운
ErrorCode.INVALID_USER_ID를 추가하거나 기존 ErrorCode.AUTHENTICATED_USER_NOT_FOUND를
재사용). 대상 메서드: extractUserId(Authentication authentication); 에러 변환 시 원인(cause)과
설명 메시지를 포함하도록 하고 필요하면 로깅을 추가해 디버깅 정보를 남기세요.
In
`@src/main/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepository.java`:
- Line 33: The query method findTopByUserIdOrderByDisplayOrderDesc returns the
max displayOrder including deleted favorites; update the repository query to
exclude deleted lockers/favorites by adding the appropriate predicate (e.g.,
change to findTopByUserIdAndLockerDeletedFalseOrderByDisplayOrderDesc or
findTopByUserIdAndDeletedFalseOrderByDisplayOrderDesc depending on the entity
field name) so only active favorites are considered when computing new
displayOrder; ensure the repository method references the correct boolean flag
on UserLockerFavoriteEntity (lockerDeleted or deleted) and update any
callers/tests accordingly.
---
Nitpick comments:
In
`@src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerProperties.java`:
- Around line 10-14: Add range validation to the DefaultOrigin record by
annotating its latitude and longitude components with appropriate Bean
Validation constraints (latitude between -90 and 90, longitude between -180 and
180) and ensure the enclosing configuration properties class is validated at
startup (e.g., annotate the configuration properties class with `@Validated` or
use `@ConfigurationPropertiesBinding` as appropriate) so invalid settings fail
fast; update DefaultOrigin (the record) to use `@DecimalMin/`@DecimalMax or
equivalent annotations on the latitude and longitude parameters and enable
validation on the containing properties bean.
In
`@src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerStoreAdapter.java`:
- Around line 50-78: The reorder method in FavoriteLockerStoreAdapter currently
throws IllegalArgumentException for various validation failures; change these to
throw BusinessException with a specific ErrorCode (e.g., INVALID_FAVORITE_ORDER
or a new code that fits your error catalog) so it matches the add() behavior;
replace each IllegalArgumentException in reorder(...) with new
BusinessException(ErrorCode.YOUR_CHOICE, "descriptive message") (for
duplicate/unknown/count-mismatch cases), and ensure any callers/tests and the
global exception mapping expect that ErrorCode.
In
`@src/main/java/com/zimdugo/locker/infrastructure/persistence/LockerEntity.java`:
- Around line 35-48: Add a global soft-delete filter to LockerEntity by
annotating the entity class (LockerEntity) with Hibernate's `@Where`(clause =
"deleted = false") so all queries automatically exclude soft-deleted rows; keep
the existing deleted field and markDeleted() method but remove ad-hoc "deleted =
false" checks from repositories; also consider adding `@SQLDelete` and `@Loader` or
a repository method using Session.enableFilter()/native query when you must
explicitly load deleted records.
In
`@src/main/java/com/zimdugo/locker/infrastructure/persistence/UserLockerFavoriteEntity.java`:
- Around line 65-68: The onCreate `@PrePersist` in UserLockerFavoriteEntity sets
createdAt with LocalDateTime.now(), which uses the JVM timezone; change the
createdAt field to an Instant (or offset-aware type) and set it using
Instant.now() in the onCreate method (or switch to database-side
CURRENT_TIMESTAMP by marking the column default), ensuring consistent UTC
timestamps; update any getters/setters/DTO mappings that reference createdAt to
handle Instant accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ee67e00f-671a-4ad5-ad56-ee1c447bf6cd
📒 Files selected for processing (28)
src/main/java/com/zimdugo/locker/application/FavoriteLockerCommandService.javasrc/main/java/com/zimdugo/locker/application/FavoriteLockerItemResponse.javasrc/main/java/com/zimdugo/locker/application/FavoriteLockerQueryService.javasrc/main/java/com/zimdugo/locker/application/FavoriteLockerResponse.javasrc/main/java/com/zimdugo/locker/application/FavoriteLockerStatusResponse.javasrc/main/java/com/zimdugo/locker/domain/FavoriteLocker.javasrc/main/java/com/zimdugo/locker/domain/FavoriteLockerPage.javasrc/main/java/com/zimdugo/locker/domain/FavoriteLockerReader.javasrc/main/java/com/zimdugo/locker/domain/FavoriteLockerStore.javasrc/main/java/com/zimdugo/locker/entrypoint/FavoriteLockerOrderUpdateRequest.javasrc/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteApi.javasrc/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteController.javasrc/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerProperties.javasrc/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerReaderAdapter.javasrc/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerStoreAdapter.javasrc/main/java/com/zimdugo/locker/infrastructure/LockerReportLatestUpdateProjection.javasrc/main/java/com/zimdugo/locker/infrastructure/LockerReportRepository.javasrc/main/java/com/zimdugo/locker/infrastructure/LockerReportStoreAdapter.javasrc/main/java/com/zimdugo/locker/infrastructure/LockerRepository.javasrc/main/java/com/zimdugo/locker/infrastructure/LockerStoreAdapter.javasrc/main/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepository.javasrc/main/java/com/zimdugo/locker/infrastructure/persistence/LockerEntity.javasrc/main/java/com/zimdugo/locker/infrastructure/persistence/UserLockerFavoriteEntity.javasrc/main/resources/application.yamlsrc/test/java/com/zimdugo/locker/entrypoint/LockerFavoriteControllerTest.javasrc/test/java/com/zimdugo/locker/infrastructure/FavoriteLockerReaderAdapterTest.javasrc/test/java/com/zimdugo/locker/infrastructure/LockerReportRepositoryTest.javasrc/test/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepositoryTest.java
| ); | ||
| } | ||
|
|
||
| private Long calculateDistanceMeters( |
There was a problem hiding this comment.
현재 postGIS 방식을 쓰고 있는데, 따로 계산을 하는 의도가 어떤것인지 궁금합니다.
| @RequiredArgsConstructor | ||
| public class FavoriteLockerReaderAdapter implements FavoriteLockerReader { | ||
|
|
||
| private static final double EARTH_RADIUS_METERS = 6_371_000; |
There was a problem hiding this comment.
아시다시피 하버사인 계산 방식으로 저희는 구현하고 있지 않은데, 지구 반지름을 사용하시는 이유가 궁금합니다
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/test/java/com/zimdugo/locker/entrypoint/LockerFavoriteControllerTest.java (1)
71-104: ⚡ Quick win위치 파라미터 누락 케이스도 목록 API 테스트에 추가해 주세요.
핵심 정책(사용자 위치 없을 때 fallback 좌표 사용) 대비, 현재는
lat/lng가 있는 요청만 검증하고 있어 회귀를 놓칠 수 있습니다.lat/lng없이도200이 반환되고 서비스가 null(또는 컨트롤러 계약값)로 호출되는 케이스를 추가하는 게 안전합니다.테스트 추가 예시
+ `@Test` + `@DisplayName`("위치 파라미터 없이도 즐겨찾기 목록을 조회한다") + void getMyFavoriteLockersWithoutLocationReturnsOk() throws Exception { + given(favoriteLockerQueryService.getFavorites(1L, 0, 20, null, null)) + .willReturn(new FavoriteLockerResponse(0, 0, 20, false, List.of())); + + mockMvc.perform(get("/api/v1/me/favorite-lockers") + .principal(authenticatedUser())) + .andExpect(status().isOk()) + .andExpect(jsonPath("$.code").value("S200")); + + verify(favoriteLockerQueryService).getFavorites(1L, 0, 20, null, null); + }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/test/java/com/zimdugo/locker/entrypoint/LockerFavoriteControllerTest.java` around lines 71 - 104, Add a new test in LockerFavoriteControllerTest that verifies the controller behavior when lat/lng are omitted: mock favoriteLockerQueryService.getFavorites(...) for the authenticated user with the expected fallback coordinates (or nulls per controller contract) — e.g. given(favoriteLockerQueryService.getFavorites(1L, 0, 20, null, null)) or the fallback values used by the controller — and return a FavoriteLockerResponse; then call mockMvc.perform(get("/api/v1/me/favorite-lockers").principal(authenticatedUser())) (no lat/lng params) and assert status isOk and the same response body assertions as getMyFavoriteLockersReturnsOk so the request without location is covered. Ensure the new test references getFavorites and LockerFavoriteControllerTest so the mock setup matches the controller's call contract.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In
`@src/test/java/com/zimdugo/locker/entrypoint/LockerFavoriteControllerTest.java`:
- Around line 71-104: Add a new test in LockerFavoriteControllerTest that
verifies the controller behavior when lat/lng are omitted: mock
favoriteLockerQueryService.getFavorites(...) for the authenticated user with the
expected fallback coordinates (or nulls per controller contract) — e.g.
given(favoriteLockerQueryService.getFavorites(1L, 0, 20, null, null)) or the
fallback values used by the controller — and return a FavoriteLockerResponse;
then call
mockMvc.perform(get("/api/v1/me/favorite-lockers").principal(authenticatedUser()))
(no lat/lng params) and assert status isOk and the same response body assertions
as getMyFavoriteLockersReturnsOk so the request without location is covered.
Ensure the new test references getFavorites and LockerFavoriteControllerTest so
the mock setup matches the controller's call contract.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 91be4d6a-6728-4573-ab75-d925b2af1bed
📒 Files selected for processing (10)
src/main/java/com/zimdugo/common/openapi/config/OpenApiConfig.javasrc/main/java/com/zimdugo/core/exception/ErrorCode.javasrc/main/java/com/zimdugo/locker/entrypoint/FavoriteLockerOrderUpdateRequest.javasrc/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteApi.javasrc/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteController.javasrc/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerStoreAdapter.javasrc/main/java/com/zimdugo/locker/infrastructure/LockerReportStoreAdapter.javasrc/main/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepository.javasrc/test/java/com/zimdugo/locker/entrypoint/LockerFavoriteControllerTest.javasrc/test/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepositoryTest.java
🚧 Files skipped from review as they are similar to previous changes (7)
- src/main/java/com/zimdugo/locker/entrypoint/FavoriteLockerOrderUpdateRequest.java
- src/main/java/com/zimdugo/locker/infrastructure/LockerReportStoreAdapter.java
- src/main/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepository.java
- src/test/java/com/zimdugo/locker/infrastructure/UserLockerFavoriteRepositoryTest.java
- src/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteController.java
- src/main/java/com/zimdugo/locker/infrastructure/FavoriteLockerStoreAdapter.java
- src/main/java/com/zimdugo/locker/entrypoint/LockerFavoriteApi.java
|
locker 조회 실패는 LOCKER_NOT_FOUND로 구분했고 reorder 과정의 일반 예외도 BusinessException(ErrorCode.BAD_REQUEST)로 정리했습니다. 누락된 import도 함께 보완하고 로컬 Swagger 실행 시 현재 접속한 서버 기준으로 요청이 나가도록 설정도 수정했습니다. |
|
즐겨찾기 목록 거리 계산도 nearby 조회와 동일하게 PostGIS 기반으로 정리하고 하버사인 계산은 제거했습니다. |
✨ 작업 내용 한 줄 요약
🛠️ 작업 내용
📚 참고 자료 (선택)
👀 리뷰 포인트 (선택)
Summary by CodeRabbit
새로운 기능
개선 사항
테스트