rk@tigase.net opened 3 weeks ago
-
Tasks & Estimates
Task Est. Time Implement Issue ↔ Commentrelationship with cascade + orphanRem1.0 h Implement PullRequest ↔ reviewersrelationship with join table0.5 h Add serialization annotations or DTO mapping 0.5 h Write integration test for Issuecomment cascade0.5 h Write integration test for PullRequestreviewer persistence0.5 h Total estimate: 3.0 hours
-
Previous Value Current Value Solidify MVP-critical domain relationships: Issue ↔ Comment, PullRequest ↔ reviewers
Solidify MVP-critical domain relationships: Issue <=> Comment, PullRequest <=> reviewers
-
Comment: Entity vs Value Object
TL;DR
Commentshould be modeled as an Entity, not a Value Object, because:- It has a distinct identity (
@Id) - It can evolve independently over time
- It may need to support auditing, authorization, or reply chaining in the future
1. Identity Matters
Each comment should be distinguishable from others, even if the content and author are the same:
Comment A: "Looks good" — by Alice on 2025-10-01 Comment B: "Looks good" — by Alice on 2025-10-02Without an ID, they would be indistinguishable. This violates domain semantics and auditability.
2. Mutable Lifecycle
A
Commentmight be:- Edited
- Flagged
- Deleted (soft-deleted for moderation)
- Used in search queries (e.g., "all comments by X")
Such behaviors require persistent identity and lifecycle management — classic signs of an Entity.
3. Futureproofing: Threads, Reactions, Permissions
Even if
Commentseems simple now, making it a Value Object locks you out of future enhancements like:- Reply-to threading (
parentCommentId) - Emoji reactions
- Role-based visibility (e.g., internal vs public comments)
- Fine-grained update tracking (edited timestamp, versioning)
Modeling it as an entity allows us to evolve the design without data model breakage.
4. Value Object Semantics Don’t Fit
A Value Object is:
- Immutable
- Interchangeable based on value equality (e.g.,
new Money(100, "USD")) - Owned by its parent entity, not shared across entities
But
Comment:- Is not interchangeable (identity matters)
- May be edited (mutable)
- Is often queried directly
5. JPA Constraint: Entities Must Have @Id
If you annotate a class with
@Entity, JPA requires a primary key. This aligns with the semantic idea that an entity must have identity — not just structure.
Conclusion
Even if we use KISS and MVP principles, making
Commentan entity provides the right foundation for extensibility, traceability, and domain integrity. - It has a distinct identity (
| Type |
Improvement
|
| Priority |
Major
|
| Assignee | |
| Version |
1.0
|
| Sprints |
n/a
|
| Customer |
n/a
|
Issue: Solidify MVP-critical domain relationships –
Issue <=> Comment,PullRequest <=> reviewersGoal
Finalize the key domain relationships needed to support Issue discussions and Pull Request review workflows in the MVP. These associations are required for REST APIs and UI display logic (e.g., showing comments under an issue, or listing reviewers for a PR).
Acceptance Criteria
Issue <=> Comment@OneToMany(mappedBy = "issue", cascade = CascadeType.ALL, orphanRemoval = true)inIssueList<Comment> commentsinIssue@ManyToOne(fetch = FetchType.LAZY)inCommentlinking back toIssue@JsonIgnore,@JsonManagedReference, or switch to DTOs for RESTPullRequest <=> reviewers@ManyToManyinPullRequest:Userneeded yetWorklog
GET /api/issues/{id}/comments