feat: ai article 여부 #203
feat: ai article 여부 #203
Conversation
Walkthrough이 변경사항은 UsersLinku 엔티티의 AI 존재 여부 필드를 isAiExist에서 aiExist로 이름을 변경하고, 관련 Getter/Setter를 업데이트하며, 데이터 타입을 Long(카운트)에서 Boolean(존재 여부)으로 변환합니다. 저장소 쿼리, 서비스 계층, DTO 전체에 걸쳐 해당 참조를 일관되게 업데이트합니다. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![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 (2)
build.gradle (1)
31-31: 불필요한 변경 사항으로 보입니다.주석 처리된 의존성 라인의 설정을 변경하는 것이 이번 PR의 목적(AI 존재 여부 필드 리팩토링)과 관련이 없어 보입니다. 의도적인 변경이 아니라면 되돌려 주세요.
src/main/java/com/umc/linkyou/web/dto/UserResponseDTO.java (1)
61-61: Boolean 필드 네이밍 컨벤션을 고려해 주세요.
myAiLinku필드의 타입이Long에서Boolean로 변경되었습니다. Boolean 필드는 일반적으로isXxx또는hasXxx형태로 명명합니다.myAiLinku대신hasAiLinku또는isAiLinkuExist같은 이름을 고려해 주세요.Also applies to: 86-86
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
build.gradle(1 hunks)src/main/java/com/umc/linkyou/domain/mapping/UsersLinku.java(1 hunks)src/main/java/com/umc/linkyou/repository/userRepository/UserQueryRepository.java(3 hunks)src/main/java/com/umc/linkyou/service/AiArticleServiceImpl.java(2 hunks)src/main/java/com/umc/linkyou/service/Linku/LinkuRecommendServiceImpl.java(1 hunks)src/main/java/com/umc/linkyou/service/Linku/LinkuServiceImpl.java(2 hunks)src/main/java/com/umc/linkyou/web/dto/UserResponseDTO.java(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (5)
src/main/java/com/umc/linkyou/service/Linku/LinkuRecommendServiceImpl.java (1)
168-168: LGTM!
getAiExist()메서드로 올바르게 업데이트되었으며,Boolean.TRUE.equals()를 사용하여 null 안전성도 확보되었습니다.src/main/java/com/umc/linkyou/service/Linku/LinkuServiceImpl.java (1)
110-110: LGTM!
getAiExist()메서드로 올바르게 업데이트되었으며,Boolean.TRUE.equals()를 사용하여 null 안전성이 확보되어 있습니다.Also applies to: 182-182
src/main/java/com/umc/linkyou/service/AiArticleServiceImpl.java (1)
133-133: LGTM!
setAiExist()및getAiExist()메서드로 올바르게 업데이트되었으며, Line 182에서는 null 체크도 적절히 수행되고 있습니다.Also applies to: 182-182
src/main/java/com/umc/linkyou/web/dto/UserResponseDTO.java (1)
97-105: API 호환성 변경사항을 확인해 주세요.
myAiLinku필드의 타입이Long(개수)에서Boolean(존재 여부)로 변경되었습니다. 이는 API 스펙의 변경이므로 다음을 확인해 주세요:
- 프론트엔드 또는 API 소비자가 이 필드를 숫자로 기대하는 경우 대응이 필요합니다.
- API 문서(Swagger 등)가 업데이트되었는지 확인해 주세요.
- 버전 관리가 필요한지 검토해 주세요.
src/main/java/com/umc/linkyou/repository/userRepository/UserQueryRepository.java (1)
50-56: Semantic change: flag-based check replaces join-based query—document maintenance contract.The query now checks
UsersLinku.aiExistflag instead of joining toai_articletable. Since AI article deletion is not implemented in the codebase, the flag won't fall out of sync currently. However, this denormalization introduces a maintenance contract:setAiExist(true)is set inAiArticleServiceImpl.java:133during article creation, but there is no corresponding reset tofalseon deletion. If article deletion is added in the future without updating this flag, the query will return incorrect results.Consider either: (1) adding explicit comment documenting that aiExist must be maintained if deletion is implemented, or (2) switching back to the join-based query if consistency is critical for user profile display.
| private Boolean aiExist = false; | ||
|
|
||
| public Boolean getAiExist() { | ||
| return this.aiExist; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f -name "UsersLinku.java" -path "*/domain/mapping/*"Repository: LinkYou-2025/LinkU_backend
Length of output: 132
🏁 Script executed:
cat -n ./src/main/java/com/umc/linkyou/domain/mapping/UsersLinku.java | head -60Repository: LinkYou-2025/LinkU_backend
Length of output: 1617
🌐 Web query:
Lombok @Getter boolean field naming convention isXxx getXxx
💡 Result:
Short answer: Lombok follows JavaBean rules — for primitive boolean fields it generates isXxx(); for Boolean it generates getXxx(); and if the field name already starts with "is" followed by an uppercase letter Lombok will not prefix another "is" (it will generate a method matching the field name). Lombok also avoids generating duplicate accessors when names conflict. (projectlombok.org)
Citations:
🌐 Web query:
Lombok duplicate method error explicit getter @Getter conflict
💡 Result:
Cause
- Lombok generates methods (getters/constructors/delegates). A "duplicate method" error appears when Lombok would generate a method that already exists (you wrote it, it exists in a superclass, or another Lombok annotation also generates it). Examples: @Getter on a field named like a superclass method (getModel), combining @NoArgsConstructor/@AllArgsConstructor/@requiredargsconstructor that both produce a no-arg constructor, or @DeleGate copying the same method twice. [1][2][3]
How to fix (pick the one that fits)
- Remove the explicit method (let Lombok generate it) or remove the Lombok annotation (keep your explicit method). [2]
- Suppress Lombok generation for a specific field: annotate the field with @Getter(AccessLevel.NONE) (or use @Setter(AccessLevel.NONE)) so Lombok won't generate that accessor. Or put @Getter on the class but @Getter(AccessLevel.NONE) on the specific field. [1]
- Rename the field so the generated accessor name doesn't clash with a superclass method. [3]
- For constructor conflicts: avoid combining annotations that produce identical constructors (write the constructor yourself, or use @SuperBuilder for inheritance-aware constructors). Use @NoArgsConstructor(force=true) only if appropriate. [2]
- For @DeleGate conflicts: use @DeleGate(excludes=...) or delegate to a narrower interface to avoid copying duplicate methods. [1][4]
- If your IDE shows the error but javac/build succeeds, ensure annotation processing is enabled and the Lombok IDE plugin is installed; sometimes IDE tooling reports false duplicates. [2]
References
- Lombok @DeleGate docs — explains delegation and excludes. [1]
- StackOverflow threads on duplicate constructors and Lombok-generated methods. [2]
- Example of getter name clash with superclass (rename/suppress solution). [3]
- VSCode/@DeleGate duplicate-method discussion. [4]
Remove duplicate getter or suppress Lombok generation for aiExist field.
The explicit getAiExist() method on lines 45-47 duplicates the getter that Lombok's @Getter annotation (line 11) generates. For Boolean wrapper type fields, Lombok generates getXxx() methods, not isXxx().
To resolve: either remove the explicit getAiExist() method and let Lombok generate it, or annotate the field with @Getter(AccessLevel.NONE) to suppress Lombok generation for this field.
Note: The field naming aiExist with getter getAiExist() follows valid Java conventions for boolean properties; the database column name is_ai_exist is also appropriate.
🤖 Prompt for AI Agents
In src/main/java/com/umc/linkyou/domain/mapping/UsersLinku.java around lines 43
to 47, there is a duplicate getter for the Boolean field aiExist that conflicts
with Lombok's @Getter on the class; remove the explicit getAiExist() method so
Lombok generates it, OR suppress Lombok for this field by adding
@Getter(AccessLevel.NONE) to the aiExist field and keep the custom getAiExist()
implementation; if you choose suppression, add the lombok.AccessLevel import and
ensure only one getter exists after the change.
#️⃣연관된 이슈
📝작업 내용
스크린샷 (선택)
💬리뷰 요구사항(선택)
Summary by CodeRabbit
변경사항
✏️ Tip: You can customize this high-level summary in your review settings.