[DDING-64] presignedUrl - 이미지 순서 적용 구현 #196
Conversation
워크스루이 풀 리퀘스트는 파일 메타데이터 관리 시스템에 순서(order) 기능을 추가하는 광범위한 변경을 포함하고 있습니다. 주요 변경 사항은 변경 사항
가능한 관련 PR
제안된 레이블
제안된 리뷰어
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: 1
🧹 Nitpick comments (19)
src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/UpdateNoticeCommand.java (1)
23-28: 필드명 오탈자 주의:imagId대신imageId사용을 권장합니다.
가독성 향상을 위해imagId를imageId로 수정해주세요.- String imagId, + String imageId,src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeNoticeServiceImpl.java (1)
53-60: 파일 URL 및 이름 조회 시 순서 처리
fileMetaDataService.getCoupledAllByDomainTypeAndEntityId(...)호출 결과를 순서만 별도로 관리하도록UploadedFileUrlAndNameWithOrderQuery.of(...)로 매핑하여, 파일 이름과 순서를 함께 담아 반환합니다. 순서를 오름차순으로 가져오고 싶다면 위 이미지 부분처럼 정렬된 쿼리 메서드(...OrderedAsc)를 고려할 수도 있습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java (1)
16-17: 새로운 필드images추가에 따른 유효성 검사 고려
images가 비어 있거나 null일 경우 처리를 어떻게 할지 확인이 필요합니다. 등록·수정 로직에서 이 필드를 정상적으로 다루는지 점검해주세요.src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java (2)
33-35: 파일 정보 변환 로직 검토
command.fileInfos()가 null인지 확인할 필요가 있습니다. 동일한 방식으로 null 체크 로직을 적용해주세요.
52-59: update 로직의 중복 개선 가능성
create와 동일하게 이미지·파일 리스트 변환 로직이 반복됩니다. 코드 중복 최소화를 위해 공통 메서드 추출을 고려해 보세요.src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/CreateNoticeCommand.java (1)
25-28: 중첩 레코드ImageInfo에서 타이포 확인이 필요합니다.
다른 곳과 동일하게imgId,imageId등으로 통일하는 것이 바람직해 보입니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java (1)
31-39: ImageInfoRequest 레코드 정의
id와order필드를 함께 관리함으로써, 이미지 순서 지정 로직에 필요한 정보를 충분히 제공해줍니다. 추가로id에 대한 유효성 검사 로직을 고려해볼 수 있습니다.src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataService.java (2)
18-18: 메서드 시그니처 포매팅
파라미터를 세로 정렬하여 가독성이 향상되었습니다. 스타일 규칙이 일관되게 유지되고 있는지 확인해 주세요.
33-34: updateWithOrder 메서드 정의
updateStatusToCoupledWithOrder를 호출하는 단계를 추가하여 확장성 있게 설계된 것으로 보입니다. 구체적인 순서 업데이트 방식에 대해 비즈니스 로직의 요구사항을 정확히 반영하고 있는지 다시 한 번 검토해보면 좋겠습니다.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (2)
28-38: toCommand 메서드 수정
UpdateNoticeCommand.builder()내부에서imageInfos와fileInfos를 변환 처리하는 로직이 간결하게 유지되고 있습니다. Null 체크 등 보강이 필요한지 확인해 주세요.
40-48: ImageInfoRequest 레코드 추가
이미지 순서를 별도로 관리할 수 있어 향후 로직 확장에 유리합니다.id형식 검증이 필요한 경우 별도 유효성 체크를 추가해도 좋겠습니다.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (1)
29-39: toCommand 메서드 변경
imageInfos와fileInfos생성 과정을 Stream으로 매핑하여 가독성이 좋고, DTO 구조가 명확합니다. 혹시 null 리스트에 대한 처리가 필요하다면 추가 구현을 고려해 주세요.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/query/CentralFixZoneQuery.java (1)
18-18: [필드 타입 일관성]
imageUrlQueries필드가 순서를 갖는 리스트로 바뀌었습니다. 본 필드를 사용하는 로직에서도 정렬, 순서 표시 등에 문제가 없는지 확인해야 합니다.src/main/java/ddingdong/ddingdongBE/domain/filemetadata/entity/FileMetaData.java (1)
87-89: [순서 업데이트 메서드]
updateOrder(int order)메서드를 통해 순서를 변경하도록 설계되었습니다. 동시성 환경에서 여러 스레드가 동시에 순서를 갱신할 경우에 대한 처리(낮은 충돌 가능성 등)를 고려하면 좋겠습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeAdminFixZoneServiceImpl.java (2)
36-36: [변수 타입 수정]
imageUrlQueries를List<UploadedFileUrlWithOrderQuery>형태로 변경하였습니다. 해당 컬렉션의 요소 각각이 순서를 담고 있기 때문에, UI나 후속 처리에서 순서를 활용하는 로직이 별도로 필요한지 고민해 보세요.
39-40: [매핑 로직]
UploadedFileUrlWithOrderQuery.of(...)메서드를 사용하여 S3 URL과fileMetaData.getOrder()를 매핑하고 있습니다. 순서 정보가 UI에서 어떻게 사용될지, 혹은 추가 정렬 로직이 필요한지 검토를 권장합니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralFixZoneServiceImpl.java (2)
38-41: 이미지 ID-순서 매핑 리스트 생성 로직 점검
FileMetaDataIdOrderDto.of()를 사용해 DTO를 만드는 부분이 명확합니다. 예외 케이스(빈 목록 등) 처리도 함께 고려해 주시면 좋겠습니다.
84-87:updateWithOrder호출 부분 확인
수정 시에도 동일하게 ID와 순서를 DTO로 전달하여 업데이트하는 구조입니다. 기존 이미지가 제거되고 새 이미지를 추가할 때, 누락이나 혼동이 없도록 주의가 필요합니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/response/AdminFixZoneResponse.java (1)
58-59:int order필드 추가
이미지 순서를 정확히 응답하기 위해 필드가 추가되었습니다. API 문서에 순서 필드에 대한 설명과 예시를 충분히 기재해 주세요.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (29)
src/main/java/ddingdong/ddingdongBE/domain/filemetadata/entity/FileMetaData.java(3 hunks)src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataService.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataServiceImpl.java(5 hunks)src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/dto/FileMetaDataIdOrderDto.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/response/AdminFixZoneResponse.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/response/CentralFixZoneResponse.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeAdminFixZoneServiceImpl.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralFixZoneServiceImpl.java(4 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/CreateFixZoneCommand.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/UpdateFixZoneCommand.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/query/AdminFixZoneQuery.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/query/CentralFixZoneQuery.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/api/AdminNoticeApi.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/api/NoticeApi.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/AdminNoticeController.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/NoticeController.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/response/NoticeResponse.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeNoticeServiceImpl.java(3 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/CreateNoticeCommand.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/UpdateNoticeCommand.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/query/NoticeQuery.java(1 hunks)src/main/java/ddingdong/ddingdongBE/file/service/dto/query/UploadedFileUrlAndNameWithOrderQuery.java(1 hunks)src/main/java/ddingdong/ddingdongBE/file/service/dto/query/UploadedFileUrlWithOrderQuery.java(1 hunks)src/main/resources/db/migration/V30__alter_table_file_meta_data_add_column_order.sql(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- src/main/resources/db/migration/V30__alter_table_file_meta_data_add_column_order.sql
- src/main/java/ddingdong/ddingdongBE/domain/notice/api/AdminNoticeApi.java
🔇 Additional comments (79)
src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/UpdateNoticeCommand.java (2)
12-13: 필드가 구조화되어 있어 변경 의도가 잘 드러납니다!
이전에는 단순히 이미지와 파일 식별자를 문자열 리스트로만 관리했지만, 이제ImageInfo,FileInfo를 사용해order같은 추가 정보도 함께 전달할 수 있게 되어 유지보수성과 확장성이 향상됩니다.
30-35: 파일 정보 구조 도입을 통해 코드 가독성이 개선되었습니다.
FileInfo를 활용해 파일 아이디와 정렬 순서를 함께 표현하는 것은 훌륭한 접근입니다.src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeNoticeServiceImpl.java (4)
12-12: 새로운 DTO Import 추가 확인
새로운UploadedFileUrlAndNameWithOrderQuery를 import하여 파일에 대한 이름과 순서를 함께 관리할 수 있게 되었습니다. 도메인 로직과 호환되도록 잘 연동되었는지 다른 부분(서비스 로직, 테스트 등)에서도 확인해 보시는 것을 권장드립니다.
14-14: 이미지 순서 관리용 DTO Import 추가 확인
UploadedFileUrlWithOrderQueryimport이 추가되어 이미지 목록을 순서대로 관리할 수 있습니다. DTO 구조가 의도대로 작동하는지, 특히 JSON 직렬화/역직렬화 과정 등이 문제없이 잘 처리되는지 점검해주세요.
34-35: Stream API 활용 문제없음
.stream().map(NoticeInfo::from).toList()로 변경된 부분이 가독성이 좋으며 불필요한 중간 단계를 줄여 성능상으로도 무난해 보입니다.
45-51: 이미지 URL 조회 시 주문(순서) 필드 반영
fileMetaDataService.getCoupledAllByDomainTypeAndEntityIdOrderedAsc(...)메서드를 통해 순서가 보장되도록 구현되었습니다.UploadedFileUrlWithOrderQuery.of(...)에서fileMetaData.getOrder()를 잘 전달하고 있어 이미지 정렬 기능이 정확히 수행될 것으로 보입니다.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/response/NoticeResponse.java (6)
4-5: 임포트 변경 확인 요청해당 임포트가 기존
UploadedFileUrlAndNameQuery,UploadedFileUrlQuery대신UploadedFileUrlAndNameWithOrderQuery,UploadedFileUrlWithOrderQuery로 변경되었습니다. 이미지와 파일에 대한 순서를 추가로 처리하기 위함으로 보이는데, 의도대로 정상 동작하는지 확인해보시면 좋겠습니다.
14-15: 레코드 필드 정의 적절성공지사항의 제목, 내용, 생성 날짜, 이미지와 파일 목록을 각각 명확하게 정의하셨습니다. Swagger 설명도 잘 작성되어 있어 API 문서화에 도움이 됩니다.
Also applies to: 17-18, 20-21, 23-24, 26-27
32-41:from(NoticeQuery query)메서드 구조Query로부터 필드를 수집 후
.builder()패턴을 사용하여NoticeResponse를 반환하는 로직이 간결하고 가독성이 좋습니다. 추후 필드가 확장되더라도 유지보수가 용이해 보입니다.
44-47:NoticeImageUrlResponse기록의 Swagger 문서스크린샷 등으로 API 문서 검증 시, 응답 필드에 대한 설명이 명확히 표시될 것으로 예상됩니다.
48-63: 이미지 응답 데이터 구조 검토
NoticeImageUrlResponse가id,order,originUrl,cdnUrl필드를 포함하여 이미지 파일의 순서를 명확히 표현합니다. 변경된 쿼리(UploadedFileUrlWithOrderQuery)를 잘 반영하고 있습니다.
65-68: 파일 응답 데이터 구조 타당성
NoticeFileUrlResponse에서 순서, 파일 이름, URL 정보를 통합적으로 담고 있어, 파일 처리를 위한 구조가 명확합니다. 이를 통해 프론트엔드 측에서도 파일 순서를 직관적으로 처리할 수 있을 것으로 보입니다.Also applies to: 69-91
src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/response/CentralFixZoneResponse.java (3)
7-7: 새로운 쿼리 클래스의 도입을 주의 깊게 확인하세요.
UploadedFileUrlWithOrderQuery로 교체함으로써 전체 코드베이스에서 해당 클래스를 사용하는 부분이 정상적으로 연동되는지 점검이 필요합니다.
61-62: 이미지 순서 필드 추가로 인한 기능 확장 확인
int order필드가 추가됨으로써 이미지 순서 정보를 명시적으로 제공할 수 있게 되었습니다. 큰 문제 없이 구현되어 보입니다.
69-73: 메서드 시그니처 변경에 따른 연동 주의
UploadedFileUrlWithOrderQuery를 사용하는 것으로 바뀌면서,order값도 함께 반환하게 되었습니다. 기존 로직과 충돌 없도록 다른 호출부가 모두 업데이트되었는지 확인해주세요.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/AdminNoticeController.java (1)
31-31: @PathVariable 제거 후 URI 매핑 확인 필요
해당 메서드 시그니처에서@PathVariable어노테이션이 제거되어, URI 경로에서noticeId를 추출하지 않는 형태로 변경되었습니다. 의도된 수정이라면 다른 곳(예: 라우팅 설정, 인터페이스, Swagger 문서 등)과의 정합성을 꼭 확인해주시기 바랍니다.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/NoticeController.java (2)
23-23: 코드 정렬에 대한 간단 의견
해당 줄에서request.toCommand()호출부의 들여쓰기가 일관성 있게 조정되어 가독성이 향상되었습니다.
29-29:@PathVariable제거 관련 동작 확인 권장
인터페이스(NoticeApi)에서 이미@PathVariable("noticeId")를 선언하고 있어, 구현체에서 생략해도 정상 동작할 것으로 예상됩니다. 다만 런타임 시점에 정상 매핑되는지 확인을 권장합니다.src/main/java/ddingdong/ddingdongBE/domain/notice/api/NoticeApi.java (1)
33-33:@PathVariable("noticeId")명시로 인한 명확성 향상
매개변수 이름을 명시적으로 지정함으로써 API 사용자 및 소스 코드 가독성이 개선되었습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java (3)
4-4: 불필요한 import가 아닌지 확인 필요
이import가 실제로 필요한지, 혹은 다른 코드에서 이미ImageInfo를 사용하지 않는지 확인해주세요.
31-38:ImageInfoRequest레코드 구조 적절
id와order를 함께 관리하여 순서 정보까지 명확히 전달할 수 있게 되었습니다. 현재 구조는 직관적이고 확장성도 좋아 보입니다.
25-27:images.stream()사용 시 NPE 방지 필요
images가 null이라면stream()호출 시 예외가 발생할 수 있습니다. 미리 null 체크를 수행하거나, 빈 리스트로 초기화하는 방안을 고려해보세요.public CreateFixZoneCommand toCommand(Long userId) { - return new CreateFixZoneCommand( + List<ImageInfoRequest> safeImages = (images == null) ? List.of() : images; + return new CreateFixZoneCommand( userId, title, content, - images.stream() + safeImages.stream() .map(image -> new ImageInfo(image.id, image.order())) .toList() ); }src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java (6)
5-5: 새 DTO 불러오기
FileMetaDataIdOrderDto사용을 위해 필요한 import로 보이므로 적절해 보입니다.
8-9: CreateNoticeCommand 내부 타입 사용
FileInfo,ImageInfo를 직접 import하여 가독성이 향상되었습니다. 의도가 명확하므로 승인합니다.
11-11: List import 확인
이미 다른 곳에서List를 사용 중이므로 중복 import는 아닌지 확인해 주세요. 불필요하다면 제거가 필요할 수 있습니다.
29-31: 이미지 정보 변환 시 null 체크 필요
command.imageInfos()가 null이면 stream()에서 예외가 발생합니다. 변경 요청 로직에서 NPE를 방지하기 위해 null이 아닌지 확인이 필요합니다.
37-44: 파일 상태 업데이트 시 예외처리 고려
updateStatusToCoupledWithOrder메서드를 호출할 때 예외 상황(예: 잘못된 ID, DB 연결 문제 등)에 대한 처리 방안이 있는지 확인해 주세요.
60-63: 파일 메타데이터 업데이트 시 순서 정보 반영
updateWithOrder를 통해 순서를 업데이트하고 있으므로 기존 로직과 충돌이 없는지 테스트 케이스 점검을 권장합니다.src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/dto/FileMetaDataIdOrderDto.java (2)
3-6: 파일 메타데이터 ID와 순서를 묶은 구조
ID와 순서를 한 번에 다루기 편리한 구조로, 다른 서비스 계층에서도 재활용하기 좋습니다.
9-11: 정적 팩터리 메서드 사용 권장
of메서드를 통해 인스턴스를 안전하게 생성하므로 유지보수성과 가독성이 좋아집니다.src/main/java/ddingdong/ddingdongBE/file/service/dto/query/UploadedFileUrlWithOrderQuery.java (2)
3-8: 파일 URL과 순서를 함께 반환하는 구조
현재 필드 구성은 직관적이어서, 클라이언트 단에서 순서 기반 처리를 쉽게 할 수 있습니다.
10-16: 정적 메서드 활용으로 생성 과정 단순화
of메서드에서UploadedFileUrlQuery와order를 합쳐 손쉽게 객체를 생성하므로 가독성과 유지보수에 도움이 됩니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/UpdateFixZoneCommand.java (2)
10-10:imageInfos로 구조 변경
이전fixZoneImageIds에서 더욱 풍부한 정보를 담도록 변경되었습니다. 주문(순서)까지 함께 전달해 확장성이 좋습니다.
20-23: 내부ImageInfo레코드 구조
imagId와order를 가진 레코드로 명확히 분리하여, 도메인 계층에서 순서 정보 처리가 간단해집니다.src/main/java/ddingdong/ddingdongBE/file/service/dto/query/UploadedFileUrlAndNameWithOrderQuery.java (2)
3-9: 레코드 구조가 간결하고 유지보수에 용이해 보입니다.
정적 팩토리 메서드 사용으로 객체 생성을 명시적으로 표현하는 점이 좋습니다. 생성자 파라미터 순서와 필드 정의 순서가 일관되어서 가독성도 뛰어납니다.
11-18: 정적 메서드 네이밍과 매개변수 한정이 명확합니다.
of메서드로UploadedFileUrlAndNameQuery와order를 조합해 레코드를 생성하는 방식이 역할이 뚜렷하고, 코드의 의도를 분명히 드러냅니다. 추가 로직이 있다면 밸리데이션 로직도 여기에 두어도 좋겠습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/CreateFixZoneCommand.java (1)
11-11:imageInfos필드 이름이 직관적이며 구조가 개선되었습니다.
단순 ID 리스트 대신ImageInfo레코드 사용으로 이미지 순서를 포함한 다양한 정보를 효율적으로 다룰 수 있게 되어 코드 확장성에 유리합니다.src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/CreateNoticeCommand.java (2)
10-14: 이미지·파일 정보를 상세화하여 관리하는 접근이 바람직합니다.
imageInfos,fileInfos를 통해 순서 정보를 함께 전송받을 수 있어, 기존보다 명확한 도메인 모델링이 가능해졌습니다.
32-35:FileInfo레코드 설계가 일관성을 유지하고 있습니다.
FileInfo와ImageInfo모두 동일한 구조로 순서 관리가 가능해, 추가 요구사항이 있을 때 확장에 용이합니다.src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/query/NoticeQuery.java (3)
4-5: 새로 도입된UploadedFileUrlWithOrderQuery및UploadedFileUrlAndNameWithOrderQuery로의 전환이 적절해 보입니다.
이미지와 파일에 순서 정보를 반영하고 있으므로, 향후 조회 로직에서도 일관성이 유지될 것으로 예상됩니다.
12-16: 필드 명 및 타입 변경으로 가독성과 유지보수성이 향상되었습니다.
images와files필드가 별도의 DTO 타입을 사용해 명확하게 정의되므로, 비즈니스 로직에서도 의도를 쉽게 파악할 수 있습니다.
19-30: 정적 메서드of의 변경 사항이 코드 일관성을 준수하고 있습니다.
새로운 DTO 리스트 타입을 안전하게 받아서 빌더에 세팅하기 때문에, 추가적인 예외 처리나 밸리데이션이 필요하다면 이 부분에 보완하면 좋겠습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java (3)
4-4: Import 구문 확인 완료
해당 import 구문은ImageInfo클래스를 사용하기 위해 추가된 것으로 보이며, 적절하게 작성되었습니다.
16-17: 픽스존 이미지 목록 필드 추가
images필드는 이미지를 식별자와 순서 정보로 묶어 관리하기에 적합해 보입니다.@Schema활용으로 API 문서화도 잘 이루어져 있습니다.
25-27: Stream 처리 검토
images.stream().map(image -> new ImageInfo(image.id(), image.order())).toList()구문은 DTO 변환 로직이 간결하고 명확하게 표현되어 있습니다. 변환 과정에서 예외 처리가 필요한지는 확인이 필요할 수 있지만, 현재로서는 문제 없어 보입니다.
[approve]src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataService.java (2)
5-5: FileMetaDataIdOrderDto import 추가
새롭게 추가된 DTO를 서비스 계층에서 활용하려는 의도가 명확하며, import 구문 자체에는 문제 없습니다.
26-27: updateStatusToCoupledWithOrder 메서드 정의
파일 메타데이터를 순서와 함께 ‘Coupled’ 상태로 업데이트하는 핵심 메서드로 보입니다. DTO 사용으로 파라미터가 명확하게 전달되는 점이 좋습니다. 내부 구현 시 null/empty 리스트에 대한 추가 검증이 필요할 수 있으니 확인해주세요.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (6)
4-5: 새로운 import 추가
FileInfo와ImageInfo를 사용하기 위한 import 구문입니다. 파일 이름과 일치하여 의미가 명확합니다.
11-13: 공지사항 제목 필드 검증
@NotNull과@Schema를 통해 필수 입력을 보장하고 API 문서를 충실히 제공하고 있습니다.
15-17: 공지사항 내용 필드 검증
제목 필드와 동일하게 필수 항목으로 지정되어 있으며, 유효성 검증 처리가 정상적으로 보입니다.
19-20: 이미지 정보 목록 필드 추가
images를 통해 이미지 식별자와 순서를 함께 관리하며, 게시물 내 이미지 배열 순서를 제어할 수 있어 유용합니다.
22-23: 파일 정보 목록 필드 추가
files필드로 첨부 파일에 대한 순서를 관리하게 된 점이 일관성과 확장성을 높이는 좋은 접근입니다.
49-56: FileInfoRequest 레코드 추가
파일 식별자와 순서를 함께 처리하여, 파일 관리 로직이 직관적이고 유지보수에 용이해졌습니다.src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (7)
4-5: FileInfo & ImageInfo import 추가
공지 생성 시 파일, 이미지를 구분하여 관리하기 위한 DTO를 가져오는 코드로, 작업 의도가 명확합니다.
12-14: 공지사항 제목 필드 추가
필수 항목에 대한 어노테이션 부여와 문서 스키마 정의가 잘 되어 있습니다.
16-18: 공지사항 내용 필드 추가
공지사항 내용 역시 필수 값으로 지정되어 있으며, 설명 어노테이션이 적절합니다.
20-21: 이미지 목록 필드 추가
images필드를 통해 이미지 순서를 지정할 수 있게 되어 사용성이 향상되었습니다.
23-24: 파일 목록 필드 추가
files필드 또한 이미지와 동일하게 파일 순서를 관리하는 데 활용될 수 있어 유연합니다.
41-48: ImageInfoRequest 레코드 정의
이미지 ID와 순서를 함께 관리하는 구조로, 반복적인 식별자 처리 로직을 단순화할 수 있습니다.
50-56: FileInfoRequest 레코드 정의
파일 ID와 순서를 함께 관리하는 구조 역시 코드 일관성을 가지며, 확장성 측면에서 적절한 설계입니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/query/AdminFixZoneQuery.java (3)
6-6: [임포트 추가 확인]
새로운UploadedFileUrlWithOrderQuery임포트를 사용해 이미지 순서를 관리하도록 변경되었습니다. 팀 내에서UploadedFileUrlQuery관련 사용처가 모두UploadedFileUrlWithOrderQuery로 일관성 있게 대체되었는지 검토가 필요합니다.
18-18: [자료형 변경]
List<UploadedFileUrlQuery>에서List<UploadedFileUrlWithOrderQuery>로 변경되었습니다. 이미지 순서를 담기 위해 필드 타입이 바뀐 만큼, AdminFixZoneQuery를 사용하는 다른 로직들도 같은 타입을 기대하도록 수정이 잘 되었는지 확인해야 합니다.
24-24: [of 메서드 파라미터 주의]
fixZoneImageUrlQueries파라미터가UploadedFileUrlWithOrderQuery로 변경됨에 따라, 이 메서드가 호출되는 모든 부분에서 타입이 올바르게 전달되고 있는지 확인이 필요합니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/query/CentralFixZoneQuery.java (2)
6-6: [임포트 추가 확인]
UploadedFileUrlWithOrderQuery임포트가 추가되어, 이미지 정보를 순서와 함께 관리할 수 있습니다. 다른 모듈에서 동일한 타입 변경이 일괄적으로 적용되었는지 살펴보세요.
24-24: [of 메서드 파라미터 변경]
fixZoneImageUrlQueries인자의 타입이 함께 변경되었습니다. 이 부분을 호출하는 서비스나 컨트롤러 계층 코드도 모두 수정되었는지 확인이 필요합니다.src/main/java/ddingdong/ddingdongBE/domain/filemetadata/entity/FileMetaData.java (2)
42-44: [새로운 컬럼 정의]
@Column(name = "file_meta_data_order", ... default 0)로order필드가 추가되었습니다. 기본값으로 0을 함께 설정하셨는데, 기존 레코드에도 적용되는지 이슈 없는지 마이그레이션 테스트가 필요합니다.
47-54: [생성자 파라미터 추가]
order값이 추가됨으로써 생성 시점에 순서 정보를 함께 주입할 수 있게 되었습니다. 도메인 로직상 생성되자마자 순서가 필요한 케이스가 있는지, 혹은 나중에 업데이트가 이뤄질지 시나리오 검토가 필요합니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeAdminFixZoneServiceImpl.java (1)
11-11: [임포트 추가]
UploadedFileUrlWithOrderQuery임포트를 통해 이미지에 대한 순서 정보를 함께 처리하게 되었습니다. 이 변경사항이 메서드 시그니처와 일치하는지 확인하세요.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralFixZoneServiceImpl.java (5)
7-7: 신규 DTO 임포트 확인
이 DTO를 통해 이미지 순서를 함께 전달하는 로직이 추가된 것 같습니다. 전반적으로 기능 구현 의도에 부합해 보이므로 승인합니다.
15-15: 이미지 URL과 순서를 함께 다루기 위한 DTO 임포트 확인
UploadedFileUrlWithOrderQuery를 사용하여 이미지 순서를 함께 다루는 부분이 예상과 일치합니다.
42-46:updateStatusToCoupledWithOrder호출 부분 확인
이미지 순서를 업데이트하며 상태를COUPLED로 변경하는 로직이 일관성 있어 보입니다. 다만 예외 발생 시 역으로 롤백되는지 확인해 주세요.
63-63: 리턴 타입 변경
List<UploadedFileUrlWithOrderQuery>로 변경되어 이미지 순서를 함께 전달 가능해졌습니다. 프론트엔드 혹은 다른 소비 측에서도 순서 정보를 적절히 사용하는지 점검이 필요합니다.
66-67: 이미지 URL 생성 시 순서 정보 주입
UploadFileUrlWithOrderQuery.of()에서fileMetaData.getOrder()를 받는 구조로 잘 연결되었습니다. 순서 번호가 제대로 반영되는지 실제 테스트도 해보시면 좋겠습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/response/AdminFixZoneResponse.java (2)
7-7:UploadedFileUrlWithOrderQuery임포트 확인
이미지 순서 정보를 담아 응답하기 위한 구조로 보이며, 변경된 로직과 어울립니다.
66-70:FixZoneImageUrlResponse.from(UploadedFileUrlWithOrderQuery query)메서드 수정
순서가 반영된 객체를 간단히 생성해 주는 로직이 적절합니다.query == null인 경우를 처리하는 것도 안정적입니다.src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataServiceImpl.java (4)
10-14: 새로운 DTO와 Map, Stream 관련 임포트
FileMetaDataIdOrderDto,Map,Collectors등을 활용하여 이미지 순서 처리를 간결하게 구현할 수 있을 것으로 보입니다.
29-29:@Override애노테이션 추가
인터페이스 정의와 일치함을 명시해 주었으므로 가독성과 유지보수성에 이점이 있습니다.
88-117:updateStatusToCoupledWithOrder메서드
- DTO에서 추출한 ID 목록과 실제 엔티티 목록의 크기를 비교해 예외를 던지는 로직이 정확합니다.
orderMap을 이용해 각 파일메타데이터의 순서를 업데이트하는 부분이 의도대로 잘 동작할 것으로 보입니다.- PENDING 상태인 파일만
COUPLED로 업데이트하므로 상태 전이도 안전해 보입니다.
141-154:updateWithOrder메서드
- 전달받은 ID 리스트와 기존에 연관된 파일메타데이터를 비교해 제거 후 갱신하는 구조가 명확합니다.
- 빈 배열 처리 시
updateStatusToDelete를 호출하는 부분도 깔끔합니다.- 내부적으로
updateStatusToCoupledWithOrder를 재사용해 중복 로직을 줄인 점이 좋습니다.
...main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/CreateFixZoneCommand.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (1)
44-59: 중복 코드 제거를 위한 리팩토링 제안
ImageInfoRequest와FileInfoRequest가 동일한 구조를 가지고 있습니다. 코드 중복을 줄이고 유지보수성을 높이기 위해 공통 인터페이스나 추상 레코드를 도입하는 것을 고려해보세요.다음과 같은 구조를 제안드립니다:
public interface OrderedResourceRequest { String id(); int order(); } public record ImageInfoRequest( @Schema(description = "이미지 식별자", example = "0192c828-ffce-7ee8-94a8-d9d4c8cdec00") String id, @Schema(description = "이미지 순서", example = "1") int order ) implements OrderedResourceRequest {} public record FileInfoRequest( @Schema(description = "파일 식별자", example = "0192c828-ffce-7ee8-94a8-d9d4c8cdec00") String id, @Schema(description = "파일 순서", example = "1") int order ) implements OrderedResourceRequest {}src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java (1)
27-33: 중복 코드 제거 필요이미지와 파일 메타데이터를 변환하는 스트림 로직이 create와 update 메서드에서 중복되어 있습니다. 이를 별도의 private 메서드로 추출하는 것이 좋겠습니다.
+ private List<FileMetaDataIdOrderDto> convertToFileMetaDataIdOrderDtos( + List<? extends FileInfoBase> infos, + Function<? super FileInfoBase, String> idExtractor) { + return infos.stream() + .map(info -> FileMetaDataIdOrderDto.of(idExtractor.apply(info), info.order())) + .toList(); + }이후 다음과 같이 사용할 수 있습니다:
List<FileMetaDataIdOrderDto> imageFileMetaDataIdOrderDtos = convertToFileMetaDataIdOrderDtos(command.imageInfos(), ImageInfo::imagId);Also applies to: 50-56
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/UpdateNoticeCommand.java(2 hunks)src/test/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralGeneralFixZoneServiceTest.java(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/UpdateNoticeCommand.java
🔇 Additional comments (16)
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (2)
27-42: 구현이 깔끔합니다!null 체크와 스트림 연산을 적절히 활용하여 DTO를 커맨드 객체로 변환하는 로직이 잘 구현되어 있습니다.
1-59: PR 목적에 잘 부합하는 구현입니다이미지 순서 적용에 대한 요구사항을 잘 반영하고 있습니다. 특히:
- FileMetaData 테이블의 order 컬럼을 활용하여 이미지 순서를 관리하는 구조가 잘 구현되어 있습니다
- 비동기적인 presigned URL 요청을 고려한 설계가 적절합니다
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (1)
28-43: toCommand 메서드의 구현이 깔끔합니다null 체크와 스트림 처리를 통한 변환 로직이 잘 구현되어 있습니다. 코드가 간결하고 이해하기 쉽습니다.
src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java (2)
35-42: 트랜잭션 처리가 적절합니다파일 메타데이터 업데이트가 트랜잭션 내에서 올바르게 처리되고 있습니다. DomainType을 통한 구분도 명확합니다.
Also applies to: 58-61
27-61: Null 안전성 검사 추가 필요command.imageInfos()와 command.fileInfos()가 null을 반환할 수 있는 경우에 대한 방어 로직이 필요합니다.
다음 스크립트로 다른 코드에서의 null 처리 패턴을 확인해보세요:
src/test/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralGeneralFixZoneServiceTest.java (3)
19-19: [임포트 추가] 적절한 ImageInfo 임포트
새로 도입된 ImageInfo를 명시적으로 임포트하여 가독성과 유지보수를 높인 점이 좋습니다.
72-72: [로직 점검] 이미지 순서 부여 확인
new ImageInfo(fileId1.toString(), 1)등으로 이미지 순서를 명시적으로 지정하여, 이미지 순서가 올바르게 적용되는지 확인할 수 있다는 점이 좋습니다. 다만 실제 서비스 로직에서 이 순서 정보가 잘 반영되는지도 추가 검증을 고려해보세요.
218-218: [설계 개선] null 대신 빈 리스트 사용
이미지 목록이 없을 때List.of()를 사용하여 NPE를 방지한 점이 유용합니다. 이 로직으로 인해 불필요한 예외 처리가 줄어들 것으로 기대됩니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java (4)
4-4: [임포트 구조] ImageInfo 임포트 도입
ImageInfo를 컨트롤러 레벨에서 임포트하여 사용함으로써, DTO 간 명확한 연계를 유지하고 있습니다. 유지보수성에 긍정적인 영향을 줄 것으로 보입니다.
16-17: [필드 추가] 이미지 정보 목록 필드images
여러 이미지를 순서대로 관리할 수 있도록images필드를 추가한 것은, 기능 요구사항을 정확히 반영한 것으로 보입니다.
25-29: [Null 처리]toCommand메서드에서 Null 방어 코드
images가 null인 경우 빈 리스트로 치환하는 로직 덕분에, 생성 시 예외를 방지하게 되어 안정성이 향상됩니다.
33-41: [중첩 레코드]ImageInfoRequest정의
이미지 식별자와 순서를 포함하는 중첩 레코드로, 정보가 명확히 캡슐화되었습니다. DTO 계층에서 데이터 구조가 명쾌하게 표현되어 이해도와 유지보수성이 높아졌습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java (4)
4-4: [임포트 구조] ImageInfo 임포트 도입
Update 시에도 이미지 정보 구조를 동일하게 활용하기 위해ImageInfo를 임포트한 점이 통일성을 높입니다.
16-17: [필드 변경]images필드로 교체
이전의 단순 문자열 리스트가 아닌,ImageInfoRequest리스트로 교체함으로써 이미지 순서를 포함한 확장된 정보를 전달할 수 있게 되었습니다.
25-29: [Null 처리]toCommand메서드에서 안전한 리스트 변환
null 방지를 위해 빈 리스트로 처리하는 로직이 적용되어, DTO에서부터 안정적인 데이터 흐름을 보장할 수 있습니다.
33-41: [중첩 레코드]ImageInfoRequest추가
이미지 ID와 순서를 모두 다룰 수 있도록 중첩 레코드를 정의하여, 확장 가능하고 직관적인 구조가 확보되었습니다.
...ain/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java
Outdated
Show resolved
Hide resolved
...ain/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (1)
46-63: 🛠️ Refactor suggestionID 필드에 대한 유효성 검사 추가 필요
이미지와 파일의 ID 필드에 UUID 형식 검증이 필요합니다:
public record ImageInfoRequest( @Schema(description = "이미지 식별자", example = "0192c828-ffce-7ee8-94a8-d9d4c8cdec00") + @Pattern(regexp = "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + message = "올바른 UUID 형식이 아닙니다") String id, // ... order field ... ) public record FileInfoRequest( @Schema(description = "파일 식별자", example = "0192c828-ffce-7ee8-94a8-d9d4c8cdec00") + @Pattern(regexp = "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + message = "올바른 UUID 형식이 아닙니다") String id, // ... order field ... )순서 필드에 대한
@Min검증이 이전 리뷰 의견대로 잘 구현되었습니다.
🧹 Nitpick comments (5)
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (1)
33-42: 스트림 연산 단순화 필요리스트가 빈 리스트로 초기화된다면 null 체크가 불필요합니다. 다음과 같이 단순화할 수 있습니다:
- .imageInfos((images != null) ? - images.stream() - .map(image -> new ImageInfo(image.id, image.order())) - .toList() : - List.of()) - .fileInfos((files != null) ? - files.stream() - .map(file -> new FileInfo(file.id, file.order())) - .toList() : - List.of()) + .imageInfos(images.stream() + .map(image -> new ImageInfo(image.id, image.order())) + .toList()) + .fileInfos(files.stream() + .map(file -> new FileInfo(file.id, file.order())) + .toList())src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java (2)
27-42: 이미지 및 파일 순서 처리 로직이 깔끔하게 구현되었습니다.스트림 API를 활용하여 이미지와 파일의 순서 정보를 명확하게 처리하고 있습니다.
순서 값에 대한 유효성 검사 추가를 고려해주세요.
현재 구현에서는 order 값에 대한 유효성 검사가 없습니다. 음수나 중복된 순서 값이 입력될 수 있습니다.
다음과 같은 검증 로직 추가를 제안드립니다:
List<FileMetaDataIdOrderDto> imageFileMetaDataIdOrderDtos = command.imageInfos().stream() + .peek(imageInfo -> { + if (imageInfo.order() < 0) { + throw new IllegalArgumentException("이미지 순서는 0 이상이어야 합니다."); + } + }) .map(imageInfo -> FileMetaDataIdOrderDto.of(imageInfo.imageId(), imageInfo.order())) .toList();
50-61: 코드 중복을 줄일 수 있는 기회가 있습니다.create와 update 메서드에서 이미지와 파일 정보를 변환하는 로직이 중복됩니다.
다음과 같은 private 메서드로 중복 코드를 추출하는 것을 고려해주세요:
private List<FileMetaDataIdOrderDto> convertToFileMetaDataIdOrderDtos( List<ImageInfo> infos) { return infos.stream() .map(info -> FileMetaDataIdOrderDto.of(info.imageId(), info.order())) .toList(); }트랜잭션 최적화를 고려해주세요.
파일 메타데이터 업데이트가 두 번 발생하는데, 이는 별도의 트랜잭션으로 처리될 수 있습니다.
성능 최적화를 위해 다음과 같은 방안을 고려해주세요:
- 이미지와 파일 메타데이터 업데이트를 병렬로 처리
- 배치 업데이트로 전환하여 데이터베이스 호출 횟수 감소
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (1)
32-41: 스트림 연산 단순화 제안
@NotNull어노테이션이 추가되면 null 체크가 불필요해지므로, 스트림 연산을 더 간단하게 작성할 수 있습니다.다음과 같이 수정을 제안드립니다:
- .imageInfos((images != null) ? - images.stream() - .map(image -> new ImageInfo(image.id, image.order())) - .toList() : - List.of()) - .fileInfos((files != null) ? - files.stream() - .map(file -> new FileInfo(file.id, file.order())) - .toList() : - List.of()) + .imageInfos(images.stream() + .map(image -> new ImageInfo(image.id, image.order())) + .toList()) + .fileInfos(files.stream() + .map(file -> new FileInfo(file.id, file.order())) + .toList())src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralFixZoneServiceImpl.java (1)
84-87: FixZone 수정 시 이미지 순서 정보 업데이트
updateWithOrder메서드를 통해 업데이트 시에도 이미지 순서를 반영하고 있습니다. 변경/삭제된 이미지 처리 로직(불필요 파일 메타데이터 정리 등)도 함께 고려될 수 있으면 좋겠습니다.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
build.gradle(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/api/ClubFixZoneApi.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralFixZoneServiceImpl.java(4 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/CreateFixZoneCommand.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/UpdateFixZoneCommand.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/api/AdminNoticeApi.java(3 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/CreateNoticeCommand.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/CreateFixZoneCommand.java
- src/main/java/ddingdong/ddingdongBE/domain/notice/api/AdminNoticeApi.java
- src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/dto/command/UpdateFixZoneCommand.java
- src/main/java/ddingdong/ddingdongBE/domain/notice/service/dto/command/CreateNoticeCommand.java
🔇 Additional comments (20)
build.gradle (2)
92-97: SonarQube 설정이 적절하게 구성되었습니다.코드 분석 및 커버리지 제외 패턴이 잘 정의되어 있습니다. 공통 코드, 컨트롤러, DTO, 일반 서비스 클래스를 제외하는 것은 적절한 접근 방식입니다.
107-110: JaCoCo 테스트 리포트 설정이 SonarQube 설정과 일관성있게 구성되었습니다.JaCoCo 테스트 커버리지 제외 패턴이 SonarQube 설정과 동일하게 유지되어 일관성이 확보되었습니다. 파일 트리 구성 방식도 Gradle best practice를 잘 따르고 있습니다.
src/main/java/ddingdong/ddingdongBE/domain/notice/service/FacadeAdminNoticeServiceImpl.java (2)
5-5: 새로운 DTO import가 적절히 추가되었습니다.파일 메타데이터의 순서 정보를 처리하기 위한
FileMetaDataIdOrderDtoimport가 올바르게 추가되었습니다.
Line range hint
1-77: PR 목표와 잘 부합하는 구현입니다.공지사항의 이미지 순서 적용에 대한 요구사항이 잘 구현되었습니다. 특히:
- 생성 시 이미지 순서 처리
- 수정 시 이미지 순서 처리
- 파일과 이미지의 명확한 구분
다만, PR 설명에서 언급된 시간 기반 UUID로 인한 순서 보장 문제가 완전히 해결되었는지 확인이 필요합니다.
✅ Verification successful
Let me check the UUID generation logic further to verify the time-based ordering.
시간 기반 UUID 문제가 해결되었습니다.
코드베이스를 검토한 결과, 시간 기반 UUID 생성 문제가 다음과 같이 해결되었습니다:
UuidCreator.getTimeOrderedEpoch()를 사용하여 시간 기반으로 정렬 가능한 UUID를 생성- 이미지 순서는
order필드를 통해 명시적으로 관리되어 UUID 순서에 의존하지 않음따라서 PR의 목표인 이미지 순서 적용이 다음 두 가지 측면에서 모두 적절하게 구현되었습니다:
- 이미지 순서의 명시적 관리
- 시간 기반 UUID 정렬 문제 해결
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # UUID 생성 로직 확인 rg -A 5 "UUID" .Length of output: 42229
Script:
#!/bin/bash # Check UuidCreator usage and implementation rg -A 5 "UuidCreator" .Length of output: 15930
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (1)
55-62: 파일 순서의 중복 검증 로직 추가 필요이미지 순서와 동일한 문제가 파일 순서에도 적용됩니다. 앞서 제안된
UniqueOrdervalidator를 파일 순서 검증에도 확장하여 적용해야 합니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/api/ClubFixZoneApi.java (3)
13-13: 유효성 검증을 위한 @Valid 임포트 추가 확인
jakarta.validation.Valid임포트가 정상적으로 추가되어 있습니다. 향후 요청 DTO의 검증 어노테이션 사용이 가능해져, 안정성을 높일 수 있습니다.
47-47: CreateFixZone API에 대한 DTO 검증 활성화
@RequestBody에@Valid가 추가되어 유효성 검증이 활성화되었습니다. 잘못된 필드값이 들어왔을 때 예외 처리가 어떻게 이뤄지는지 확인해보시면 좋겠습니다.
55-55: UpdateFixZone API에 대한 DTO 검증 활성화
Patch 메서드에도 동일하게@Valid가 적용되었습니다. 유효성 검증 결과에 따른 에러 응답이 적절히 처리되는지 테스트 케이스 작성도 권장드립니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java (4)
4-6: 유효성 검증을 위한 어노테이션 및 참조 추가 확인
ImageInfo와Min,NotNull등이 임포트되어 있으며, DTO 검증 체계를 확장하는 데 문제 없습니다.
17-18:images필드 도입으로 확장성 향상
기존fixZoneImageIds대신images리스트로 구조가 개선되었습니다. 이미지 식별자와 순서를 함께 보유할 수 있어 확장성이 좋습니다.
26-30:images를 명령 객체로 매핑하는 로직
images != null조건 검증 후,List.of()를 반환하여 NPE를 방지하는 방식이 적절합니다. 스트림으로ImageInfo객체로 변환하여 의도한 대로 잘 매핑되고 있습니다.
34-43:ImageInfoRequest중첩 레코드의 유효성 검증 및 스키마 정의
이미지 순서를 1 이상으로 제한하는@Min검증이 적절하며, Swagger 문서화를 통해 API 사용성을 높였습니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java (4)
4-6:ImageInfo임포트 및 검증 어노테이션 추가
ImageInfo와 검증 어노테이션@Min,@NotNull을 불러오면서, 요청 DTO 구조에 맞춰 유효성 검증을 체계적으로 도입했습니다.
17-18:images필드를 통한 이미지 정보 전달
기존 단순 문자열 리스트가 아닌, 이미지 식별자와 순서를 함께 담도록 개선되었습니다. 요청 구조가 좀 더 명확해졌습니다.
26-30:toCommand메서드에서images매핑 로직
null 처리 후 스트림을 통해ImageInfo로 변환하는 로직이 안정적으로 보입니다. NPE 방지와 매핑 과정이 간결합니다.
34-43:ImageInfoRequest레코드의 검사 및 문서화
이미지 순서가 1 이상이어야 한다는 조건을 제공하고, 예시를 통해 Swagger 문서화도 이뤄졌습니다. 사용성 향상에 도움이 됩니다.src/main/java/ddingdong/ddingdongBE/domain/fixzone/service/FacadeCentralFixZoneServiceImpl.java (4)
7-7: 새로운 DTOFileMetaDataIdOrderDto임포트 확인
이미지 순서를 포함해 메타데이터를 처리하기 위한 DTO 임포트가 적절합니다.
15-15:UploadedFileUrlWithOrderQuery임포트 확인
이미지 조회 결과에 순서 정보를 담기 위한 쿼리 DTO를 사용하여, 확장 계산 로직에서 유연하게 대응할 수 있습니다.
38-46: FixZone 생성 시 파일 메타데이터에 이미지 순서 반영
FileMetaDataIdOrderDto리스트를 통해 이미지 순서를 포함해updateStatusToCoupledWithOrder메서드를 호출하는 로직이 적절합니다. 이미지가 하나도 없을 경우 예외가 발생하지 않는지 확인이 필요합니다.
63-67: FixZone 조회 시 순서 정보를 함께 조회
UploadedFileUrlWithOrderQuery를 통해 이미지 URL과 순서를 함께 반환하여, 프론트엔드에서 순차적으로 보여줄 수 있습니다. 표시 우선순위를 테스트해보시기 바랍니다.
...ain/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java
Show resolved
Hide resolved
...ain/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java
Show resolved
Hide resolved
| public record ImageInfoRequest( | ||
| @Schema(description = "이미지 식별자", example = "0192c828-ffce-7ee8-94a8-d9d4c8cdec00") | ||
| String id, | ||
| @Schema(description = "이미지 순서", example = "1") | ||
| @Min(value = 1, message = "이미지 순서는 1 이상이어야 합니다") | ||
| int order | ||
| ) { | ||
|
|
||
| } |
There was a problem hiding this comment.
💡 Codebase verification
🛠️ Refactor suggestion
이미지 순서 중복 검증이 필요합니다
서비스 계층의 코드를 검토한 결과, 이미지 순서의 중복을 검증하는 로직이 구현되어 있지 않습니다. 현재 구현에서는:
FileMetaDataIdOrderDto는 단순히 ID와 순서 값을 전달하는 역할만 수행FileMetaDataService의updateWithOrder와updateStatusToCoupledWithOrder메서드에서도 순서 중복 검증을 하지 않음
다음과 같은 커스텀 validator 구현을 제안드립니다:
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = UniqueOrderValidator.class)
public @interface UniqueOrder {
String message() default "이미지 순서는 중복될 수 없습니다";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
public class UniqueOrderValidator implements ConstraintValidator<UniqueOrder, UpdateNoticeRequest> {
@Override
public boolean isValid(UpdateNoticeRequest request, ConstraintValidatorContext context) {
if (request.images() == null) return true;
Set<Integer> orders = new HashSet<>();
return request.images().stream()
.map(ImageInfoRequest::order)
.allMatch(orders::add);
}
}🔗 Analysis chain
이미지 순서의 중복 검증 로직 추가 필요
현재 이미지 순서의 최소값은 검증하고 있으나, 동일한 순서값이 여러 이미지에 지정되는 것을 방지하는 로직이 없습니다. 이는 잠재적으로 순서가 뒤섞이는 문제를 야기할 수 있습니다.
서비스 계층에서 중복 순서를 검증하는 로직이 있는지 확인이 필요합니다:
다음과 같은 커스텀 validator 추가를 제안드립니다:
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = UniqueOrderValidator.class)
public @interface UniqueOrder {
String message() default "이미지 순서는 중복될 수 없습니다";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
public class UniqueOrderValidator implements ConstraintValidator<UniqueOrder, UpdateNoticeRequest> {
@Override
public boolean isValid(UpdateNoticeRequest request, ConstraintValidatorContext context) {
if (request.images() == null) return true;
Set<Integer> orders = new HashSet<>();
return request.images().stream()
.map(ImageInfoRequest::order)
.allMatch(orders::add);
}
}Let me check the implementation of updateWithOrder and updateStatusToCoupledWithOrder methods to verify if they handle duplicate orders.
Let me try a different approach to find the implementation using ripgrep.
Let me check the implementation of FileMetaDataIdOrderDto to see if there's any duplicate order validation.
Let me check the content of FileMetaDataIdOrderDto.java file.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: 서비스 계층에서 순서 중복 검증 로직 확인
rg -A 10 "updateWithOrder|updateStatusToCoupledWithOrder" src/main/java/ddingdong/ddingdongBE/domain/notice/service/
Length of output: 3849
Script:
#!/bin/bash
# Check implementation of updateWithOrder and updateStatusToCoupledWithOrder
ast-grep --pattern 'public $_ updateWithOrder($$$) {
$$$
}'
ast-grep --pattern 'public $_ updateStatusToCoupledWithOrder($$$) {
$$$
}'
Length of output: 142
Script:
#!/bin/bash
# Find the file metadata service implementation
fd FileMetaDataService
rg -A 15 "updateWithOrder|updateStatusToCoupledWithOrder" --type java
Length of output: 16065
Script:
#!/bin/bash
# Find FileMetaDataIdOrderDto implementation
fd FileMetaDataIdOrderDto
rg -A 10 "class FileMetaDataIdOrderDto" --type java
Length of output: 177
Script:
#!/bin/bash
cat src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/dto/FileMetaDataIdOrderDto.java
Length of output: 446
| @@ -39,15 +39,19 @@ public class FileMetaData extends BaseEntity { | |||
| @Column(nullable = false) | |||
| private FileStatus fileStatus; | |||
|
|
|||
| @Column(name = "file_meta_data_order", nullable = false, columnDefinition = "integer default 0") | |||
There was a problem hiding this comment.
default를 0으로 설정해서 null값을 가질 일이 없어지는 것일까요?!
There was a problem hiding this comment.
맞습니다! order를 primitive type으로 해서 nullable하게 할 경우 조회 시 null값일 경우 에러가 발생해 해당 방식으로 지정했습니다.
src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/dto/FileMetaDataIdOrderDto.java
Outdated
Show resolved
Hide resolved
src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataService.java
Show resolved
Hide resolved
| (images != null) ? | ||
| images.stream() | ||
| .map(image -> new ImageInfo(image.id, image.order())) | ||
| .toList() : | ||
| List.of() |
There was a problem hiding this comment.
p3)
가독성을 위해 따로 변수를 선언해도 좋아보입니다!
There was a problem hiding this comment.
해당 부분은 npe 방지를 위한 코드라 따로 메서드로 추출하는게 더 가독성이 안좋을거 같습니다..!
별개로 기존 api스펙에선 해당 부분이 nullable한 필드였는데, 이번 작업으로 인해 해당 필드가 null일 경우 stream 동작시 npe 발생해서 조치가 필요한 상황입니다. 우선은 기존 스펙을 유지하기 위해 위와같이 처리했는데, api스펙 차원에서 null을 허용 안하는것과 어떤 것이 나을까요?
개인적으론 후자가 나을거 같긴 합니다!
| @@ -54,17 +55,19 @@ public static AdminFixZoneResponse from(AdminFixZoneQuery query) { | |||
| description = "어드민 - 픽스존 이미지 URL 조회 응답" | |||
| ) | |||
| record FixZoneImageUrlResponse( | |||
| @Schema(description = "이미지 순서", example = "1") | |||
| int order, | |||
There was a problem hiding this comment.
p3)
회의 중에 백엔드 내에서 순서대로 정렬하여 응답해준다고 하여 클라이언트에서는 신경 쓸 필요가 없다고 했는데, 순서를 응답값에 포함한 이유가 있나요!?
There was a problem hiding this comment.
update시 순서를 클라이언트에서 인식해서 지정해줘야해서 order를 응답에 포함시켰습니다!
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/response/NoticeResponse.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (1)
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (1)
20-24: 🛠️ Refactor suggestion이미지와 파일 목록의 크기 제한과 Null 검증 필요
성능과 안정성을 위해 목록의 크기 제한과 null 검증이 필요합니다.
🧹 Nitpick comments (7)
src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java (2)
26-30: Null 체크 로직 개선이 필요합니다현재 구현된 null 체크 로직은 개선의 여지가 있습니다. Optional을 사용하면 더 깔끔한 코드를 작성할 수 있습니다.
다음과 같이 수정하는 것을 제안합니다:
- (images != null) ? - images.stream() - .map(image -> new ImageInfo(image.id, image.order())) - .toList() : - List.of() + Optional.ofNullable(images) + .map(list -> list.stream() + .map(image -> new ImageInfo(image.id, image.order())) + .toList()) + .orElse(List.of())
Line range hint
1-43: API 문서화 개선이 필요합니다현재 Swagger 문서화가 기본적인 수준에 머물러 있습니다. API 사용자의 이해를 돕기 위해 더 자세한 설명이 필요합니다.
다음과 같은 개선을 제안합니다:
public record UpdateFixZoneRequest( @NotNull - @Schema(description = "제목") + @Schema(description = "픽스존 제목", example = "컴퓨터실 프린터 고장", maxLength = 100) String title, @NotNull - @Schema(description = "내용") + @Schema(description = "픽스존 상세 내용", example = "3층 컴퓨터실 프린터가 용지 걸림으로 인해 작동하지 않습니다") String content, - @Schema(description = "픽스존 이미지 정보 목록") + @Schema(description = "픽스존 이미지 정보 목록. 이미지는 최대 5개까지 첨부 가능하며, order 값으로 표시 순서를 지정할 수 있습니다") List<ImageInfoRequest> imagessrc/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataServiceImpl.java (2)
141-154: 로깅 개선이 필요합니다.파일 메타데이터 업데이트 중 발생하는 주요 이벤트들에 대한 로깅이 부족합니다. 다음과 같은 로깅 추가를 제안드립니다:
@Transactional @Override public void updateWithOrder(List<FileMetaDataIdOrderDto> fileMetaDataIdOrderDtos, DomainType domainType, Long entityId) { if (fileMetaDataIdOrderDtos == null || fileMetaDataIdOrderDtos.isEmpty()) { + log.info("파일 메타데이터 목록이 비어있어 전체 삭제를 진행합니다. domainType={}, entityId={}", + domainType, entityId); updateStatusToDelete(domainType, entityId); return; } + log.debug("파일 메타데이터 순서 업데이트 시작. domainType={}, entityId={}, totalFiles={}", + domainType, entityId, fileMetaDataIdOrderDtos.size()); List<String> ids = fileMetaDataIdOrderDtos.stream() .map(FileMetaDataIdOrderDto::fileMetaDataId) .toList(); deleteOldIds(ids, domainType, entityId); updateStatusToCoupledWithOrder(fileMetaDataIdOrderDtos, domainType, entityId); + log.info("파일 메타데이터 순서 업데이트 완료. domainType={}, entityId={}", domainType, entityId); }
Line range hint
1-193: 전반적인 구현이 PR 목적에 잘 부합합니다.Notice와 FixZone 도메인의 이미지 순서 적용에 대한 요구사항이 잘 구현되었습니다. 특히:
- 비동기 presigned URL 요청으로 인한 순서 보장 문제를
order필드를 통해 적절히 해결하였습니다.- 생성과 수정 시나리오 모두에 대한 처리가 잘 구현되어 있습니다.
- 트랜잭션 처리와 예외 처리가 적절히 되어 있습니다.
다만, 다음 사항들을 추가로 고려해보시면 좋을 것 같습니다:
- 대용량 이미지 처리 시의 성능 테스트
- 순서 변경이 잦은 경우에 대한 처리 최적화
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (1)
33-42: Null 체크를 검증 계층으로 이동 필요서비스 계층에서 수행하는 null 체크를 DTO 레벨의 검증으로 이동하면 더 명확한 API 계약이 될 것 같습니다.
다음과 같이 수정을 제안드립니다:
@Schema(description = "공지사항 이미지 정보 목록") + @NotNull(message = "이미지 정보 목록은 null일 수 없습니다") List<ImageInfoRequest> images = List.of(), @Schema(description = "공지사항 파일 정보 목록") + @NotNull(message = "파일 정보 목록은 null일 수 없습니다") List<FileInfoRequest> files = List.of()src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java (2)
41-47: 이미지 정보 변환 로직 중복 제거 필요
CreateNoticeRequest와UpdateNoticeRequest사이에 이미지 정보 변환 로직이 중복되어 있습니다.공통 유틸리티 클래스를 만들어 중복을 제거하는 것을 제안드립니다:
public class NoticeRequestUtils { public static List<ImageInfo> toImageInfos(List<? extends BaseImageInfoRequest> images) { return (images != null) ? images.stream() .map(image -> new ImageInfo(image.id(), image.order())) .toList() : List.of(); } public static List<FileInfo> toFileInfos(List<? extends BaseFileInfoRequest> files) { return (files != null) ? files.stream() .map(file -> new FileInfo(file.id(), file.order())) .toList() : List.of(); } }
49-57: 비동기 처리 시 이미지 순서 보장 방안 검토 필요PR 목적에서 언급된 비동기 presigned URL 요청으로 인한 이미지 순서 문제가 현재 구현에서 완전히 해결되지 않은 것 같습니다.
다음 사항들을 고려해보시면 좋을 것 같습니다:
- 클라이언트에서 이미지 업로드 완료 후 순서 정보를 포함하여 한 번에 요청하는 방식
- 임시 저장소를 활용하여 이미지 업로드 완료 후 최종 저장하는 방식
- 이미지 업로드 상태를 추적하여 모든 업로드가 완료된 후 순서를 적용하는 방식
Also applies to: 59-66
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
build.gradle(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataService.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataServiceImpl.java(5 hunks)src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/dto/FileMetaDataIdOrderDto.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java(2 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java(1 hunks)src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/UpdateNoticeRequest.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/dto/FileMetaDataIdOrderDto.java
- src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataService.java
- build.gradle
- src/main/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/CreateFixZoneRequest.java
🔇 Additional comments (2)
src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataServiceImpl.java (1)
10-10: 코드 변경사항이 적절합니다!새로운 기능을 위한 import 추가와
@Override어노테이션 추가가 잘 되었습니다.Also applies to: 12-12, 29-29
src/main/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java (1)
21-25: 🛠️ Refactor suggestion이미지와 파일 목록의 크기 제한 필요
성능과 리소스 관리를 위해 이미지와 파일 목록의 최대 크기를 제한하는 것이 좋습니다.
다음과 같이 수정을 제안드립니다:
@Schema(description = "공지사항 이미지 정보 목록") + @Size(max = 10, message = "이미지는 최대 10개까지만 등록 가능합니다") List<ImageInfoRequest> images, @Schema(description = "공지사항 파일 정보 목록") + @Size(max = 5, message = "파일은 최대 5개까지만 등록 가능합니다") List<FileInfoRequest> filesLikely invalid or redundant comment.
...n/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java
Show resolved
Hide resolved
...n/java/ddingdong/ddingdongBE/domain/fixzone/controller/dto/request/UpdateFixZoneRequest.java
Show resolved
Hide resolved
src/main/java/ddingdong/ddingdongBE/domain/filemetadata/service/FileMetaDataServiceImpl.java
Show resolved
Hide resolved
...ain/java/ddingdong/ddingdongBE/domain/notice/controller/dto/request/CreateNoticeRequest.java
Show resolved
Hide resolved
|
🚀 작업 내용
이미지 순서가 지정되어야 하는 특정 도메인(Notice, FixZone)의 요구사항에 따라 이미지 순서 적용 로직 구현
FileMetaData 테이블의 order 컬럼을 통해 이미지의 순서 부여
FileMetaDataService:updateStatusToCoupledWithOrder(),updateWithOrder()구현Notice
FixZone
🤔 고민했던 내용
다른 해결책으로 다중 이미지 첨부를 위한 presignedUrl을 다중으로 생성 정렬 후 응답하여 클라이언트 측에서 첨부 이미지 순서에 맞게 적절한 presignedUrl을 사용하는 방식도 생각해보았지만, 이미지 수정 시 새로 첨부된 이미지는 항상 후순위 이미지이기 때문에 해당 방식도 사용할 수 없었습니다.
💬 리뷰 중점사항
Summary by CodeRabbit
새로운 기능
버그 수정
리팩토링