[Feat] McpAccessToken 엔티티 및 Flyway 마이그레이션 추가

[kangcheolung]

🔍 작업 내용

• Closes [Feat] mcp_access_tokens 토큰 추가 #7

✨ 상세 설명

• V26__create_mcp_access_tokens.sql Flyway 마이그레이션 추가
• McpAccessToken JPA 엔티티 추가 (domain/user/entity/)
• FK는 @manytoone(fetch = LAZY) + @joincolumn으로 처리
• updated_at 없는 스키마라 BaseEntity 미상속, created_at 직접 관리

🛠 추후 리팩토링 및 고도화 계획

• Repository / Service / Controller 레이어 구현
• 토큰 발급 및 검증 로직 추가

📸 스크린샷 (선택)

💬 리뷰 요구사항

Summary by CodeRabbit

• New Features
  • 사용자별 접근 토큰을 저장하고 관리할 수 있는 기능이 추가되었습니다.
  • 토큰 생성 시각, 마지막 사용 시각, 폐기 시각을 함께 기록할 수 있습니다.
  • 토큰이 폐기되었는지 확인할 수 있어 상태 관리가 쉬워졌습니다.
• Database
  • 접근 토큰을 위한 새 데이터 저장 구조가 추가되었고, 사용자 기준 조회 성능을 높이기 위한 인덱스가 포함되었습니다.

[coderabbitai]

📝 Walkthrough

Walkthrough

mcp_access_tokens 테이블을 생성하는 새 데이터베이스 마이그레이션(V26)과, 이 테이블에 매핑되는 McpAccessToken JPA 엔티티가 추가되었습니다. 엔티티는 사용자 참조, 토큰 해시, 생성/사용/폐기 시각 필드와 토큰 사용 기록, 폐기 처리, 폐기 여부 확인 메서드를 제공합니다.

Changes

MCP 액세스 토큰 관리

Layer / File(s)	Summary
테이블 스키마 및 엔티티 구현 src/main/resources/db/migration/V26__create_mcp_access_tokens.sql, src/main/java/com/opensource/docgrid/domain/user/entity/McpAccessToken.java	user_id FK, token_hash, created_at(now() 기본값), last_used_at, revoked_at 컬럼과 user_id 인덱스를 가진 mcp_access_tokens 테이블을 생성하고, 이를 매핑하는 McpAccessToken 엔티티에 빌더 생성자(createdAt을 now()로 초기화)와 recordUsage, revoke, isRevoked 메서드를 구현한다.

Estimated code review effort: 2 (Simple) | ~10 minutes

버그 관점에서 보면 recordUsage/revoke 메서드가 파라미터로 시각을 그대로 받아 저장하는 구조라 호출 측에서 잘못된 시각(예: 과거 시각)을 넘겨도 검증 로직이 없어 보이는데, 엔티티 내부에서 now() 자체를 사용하도록 캡슐화하면 클린코드 관점에서 더 안전할 듯 합니다. 그 외 스키마와 엔티티는 단순 매핑이라 SOLID 위반이나 성능 이슈는 눈에 띄지 않네요.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	제목이 McpAccessToken 엔티티와 Flyway 마이그레이션 추가라는 핵심 변경을 정확히 요약합니다.
Description check	✅ Passed	필수 섹션은 모두 있고 작업 내용과 상세 설명, 추후 계획이 채워져 있어 템플릿 요구를 대부분 충족합니다.
Linked Issues check	✅ Passed	이슈 #7의 핵심 요구인 SQL 마이그레이션과 McpAccessToken 엔티티 추가가 모두 반영되었습니다.
Out of Scope Changes check	✅ Passed	변경은 엔티티와 테이블 추가 범위에 맞고, 연관 없는 코드 변경은 보이지 않습니다.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/7

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (2)

src/main/resources/db/migration/V26__create_mcp_access_tokens.sql (1)

5-11: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

token_hash 조회 성능 및 무결성 확보 필요

토큰 검증 로직(후속 작업)에서는 token_hash로 레코드를 조회할 가능성이 높습니다. 현재 user_id에만 인덱스가 있고 token_hash에는 인덱스나 유니크 제약이 없어, 토큰 검증 시 풀스캔이 발생하고 해시 충돌 시 중복 저장을 막을 방법이 없습니다.

♻️ 제안: 유니크 인덱스 추가

 CREATE INDEX idx_mcp_access_tokens_user_id ON mcp_access_tokens (user_id);
+CREATE UNIQUE INDEX uk_mcp_access_tokens_token_hash ON mcp_access_tokens (token_hash);

🤖 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/resources/db/migration/V26__create_mcp_access_tokens.sql` around
lines 5 - 11, The mcp_access_tokens table definition currently indexes only
user_id, so token_hash lookups may be slow and duplicate hashes are not
prevented. Update the V26__create_mcp_access_tokens.sql migration to add a
unique index or unique constraint on token_hash alongside the existing
mcp_access_tokens table definition, keeping the current user_id index intact, so
the later token validation flow can query by token_hash efficiently and enforce
hash uniqueness.

src/main/java/com/opensource/docgrid/domain/user/entity/McpAccessToken.java (1)

52-65: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

시각 처리 방식 일관성 개선 제안

생성자는 내부적으로 LocalDateTime.now()를 사용하는데, recordUsage/revoke는 호출자가 시각을 직접 넘기도록 되어 있습니다. 호출자가 잘못된 시각을 전달하면 created_at보다 이른 last_used_at/revoked_at이 저장될 수 있어 일관성이 떨어집니다.

♻️ 제안: 엔티티 내부에서 시각 결정

-    public void recordUsage(LocalDateTime usedAt) {
-        this.lastUsedAt = usedAt;
+    public void recordUsage() {
+        this.lastUsedAt = LocalDateTime.now();
     }

-    public void revoke(LocalDateTime revokedAt) {
-        this.revokedAt = revokedAt;
+    public void revoke() {
+        this.revokedAt = LocalDateTime.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/opensource/docgrid/domain/user/entity/McpAccessToken.java`
around lines 52 - 65, McpAccessToken has inconsistent time handling because the
constructor sets createdAt internally with LocalDateTime.now() while recordUsage
and revoke accept arbitrary timestamps from callers. Update the McpAccessToken
methods so the entity controls its own timestamps consistently, either by
setting lastUsedAt/revokedAt inside recordUsage/revoke using the current time or
by aligning the constructor and lifecycle methods to a single time-source
approach. Use the McpAccessToken constructor, recordUsage, and revoke as the
reference points when making the change.

🤖 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/main/java/com/opensource/docgrid/domain/user/entity/McpAccessToken.java`:
- Around line 52-65: McpAccessToken has inconsistent time handling because the
constructor sets createdAt internally with LocalDateTime.now() while recordUsage
and revoke accept arbitrary timestamps from callers. Update the McpAccessToken
methods so the entity controls its own timestamps consistently, either by
setting lastUsedAt/revokedAt inside recordUsage/revoke using the current time or
by aligning the constructor and lifecycle methods to a single time-source
approach. Use the McpAccessToken constructor, recordUsage, and revoke as the
reference points when making the change.

In `@src/main/resources/db/migration/V26__create_mcp_access_tokens.sql`:
- Around line 5-11: The mcp_access_tokens table definition currently indexes
only user_id, so token_hash lookups may be slow and duplicate hashes are not
prevented. Update the V26__create_mcp_access_tokens.sql migration to add a
unique index or unique constraint on token_hash alongside the existing
mcp_access_tokens table definition, keeping the current user_id index intact, so
the later token validation flow can query by token_hash efficiently and enforce
hash uniqueness.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fb1762c6-c4e6-40da-baf5-5dd81c26a8dd

📥 Commits

Reviewing files that changed from the base of the PR and between 6f751e9 and 1d2d1bb.

📒 Files selected for processing (2)

• src/main/java/com/opensource/docgrid/domain/user/entity/McpAccessToken.java
• src/main/resources/db/migration/V26__create_mcp_access_tokens.sql