Validate transactional handling in RootCommentShowService - no changes required

[Copilot]

Addressed review concern about removing @Transactional from RootCommentShowService. The current implementation is correct.

Analysis

QueryDSL without @Transactional works correctly:

• Spring Boot's OpenSessionInView (default enabled) provides HTTP request-scoped Hibernate Session
• JPAQueryFactory uses this session for read queries without explicit transaction
• No persistence context issues occur

StatusFilterAspect requires @Transactional to activate:

// Pointcut only matches when @Transactional is present
@Around("(@annotation(org.springframework.transaction.annotation.Transactional) || @within(...)) && !@annotation(IncludeInactive) && !@annotation(Unfiltered)")
public Object enableActiveByDefault(ProceedingJoinPoint pjp) { ... }

Manual status filtering is intentional:

// CommentQueryRepositoryImpl.java:24
// "댓글 관련 queryDsl 코드에서는 status 값 명시해야함 (서비스 메서드에서 status filter off가 전제)"

// Query deliberately excludes comment.status filtering to retrieve INACTIVE records
BooleanExpression whereClause = comment.postJpaEntity.postId.eq(postId)
    .and(comment.parent.isNull())
    .and(commentCreator.status.eq(ACTIVE))  // Only filters creator status
    // No filter on comment.status - retrieves both ACTIVE and INACTIVE

Why Adding @Transactional Would Break Logic

1. StatusFilterAspect would activate and force ACTIVE-only filtering at Hibernate level
2. findLatestRootCommentsWithDeleted would fail to retrieve INACTIVE comments
3. Service layer's deleted comment handling logic (if (root.isDeleted())) would never execute

Conclusion

Current design correctly avoids @Transactional to prevent aspect interference with manual status control.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.