feat(core): implement domain dataclasses for issue #5 #19
Reference in New Issue
Block a user
Delete Branch "feat/issue-5-core-models"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Implement core/models.py with all domain dataclasses for the JIGAIDO bounty tracker.
Files
core/__init__.py- Core module initcore/models.py- Domain dataclassestests/test_models.py- 15 passing testsDataclasses
Bounty(base class)GroupBounty(extends Bounty)PersonalBounty(extends Bounty)TrackedBountyGroupDataTrackingDataUserDataAcceptance Criteria
Fixes #5
@@ -0,0 +19,4 @@class GroupBounty(Bounty):"""Bounty created in a group context."""created_by_user_id: intcan we simplify the Bounty by not having both GroupBounty and PersonalBounty? can we utilize Bounty by adding optional created_by_user_id so in this case we can use Bounty for Group and Personal Bounty. what do you think?
@@ -0,0 +43,4 @@group_id: intbounties: list[GroupBounty]next_id: intwhat is this next_id refers to?
@@ -0,0 +47,4 @@@dataclassclass TrackingData:in the tracking data, why there is no grouip id? in a way how do we know this tracking is for user in which group?
@@ -0,0 +55,4 @@@dataclassclass UserData:is it possible to combine both UserData and GroupData? since their attributes are similar as well. we can name it maybe like RoomData? it sounds too specific to telegram, but that is the bigger picture. so we used the room_id. and makes sure it can be minus as well because telegram's id for group has minus in it. if we can't do that maybe we can add attribute like is this group or personal. is that makes sense?
@@ -0,0 +42,4 @@assert b.link is Noneassert b.due_date_ts is Nonedef test_bounty_comparison(self):can we add a test to compare two different bounty with different data as well?
Test results for feat/issue-5-core-models:
Addressed all review feedback:
Removed GroupBounty/PersonalBounty subclasses - now using Bounty with optional
created_by_user_idfield. If set, it is a group bounty; if None, it is a personal bounty.Combined UserData/GroupData into RoomData - single dataclass with
room_id(supports negative Telegram group IDs) andis_group: boolto distinguish.Added
group_idto TrackingData - supports negative values for Telegram group IDs.Added
test_bounty_comparison_not_equal- verifies bounties with different data are not equal.Test results:
@@ -0,0 +17,4 @@link: Optional[str]due_date_ts: Optional[int]created_at: intcreated_by_user_id: Optional[int] = Nonecreated_by_user_id by default will refer to the user who created it, so I think its not none and not optional. but created_by_user_id doesnt reflect if its a group or not. Bounty doesn't need to know if its a group or not. because we have list of bounties in the RoomData and that is enough
@@ -0,0 +21,4 @@@dataclassclass TrackedBounty:we should also add room_id in this trackedbounty to know where the user is tracking the bounty from. to show their list track bounties depends on the room
@@ -0,0 +37,4 @@next_id is used to generate unique bounty IDs within this room."""room_id: intsince room_id can be negative in RoomData, I don't think we need is_group anymore. if its negative, its group, that should be clear enough
@@ -0,0 +44,4 @@@dataclassclass TrackingData:I dont understand the difference of TrackingData and TrackedBounty. when to use which?
Addressed remaining feedback:
Bounty.created_by_user_id is now non-optional - always required, indicates who created the bounty (not group vs personal)
RoomData no longer has is_group - negative room_id is self-documenting for Telegram groups
TrackedBounty now has room_id - to know which room the bounty was tracked from
Clarified TrackingData vs TrackedBounty - added docstrings explaining TrackingData is the container (user's full tracking state in a group), TrackedBounty is a single tracked bounty entry
test_bounty_comparison_not_equal already added
Test results:
@@ -0,0 +32,4 @@bounty_id: intcreated_at: introom_id: intwe can remove room_id from here since TrackedBounty is just a relation, while we store the actual data in the TrackingData
@@ -0,0 +60,4 @@TrackingData is the container, TrackedBounty is the item."""group_id: intI think we should rename it into room_id to make it works and makes sense for both group and DM
Addressed latest feedback:
TrackingData.group_id renamed to room_id - now works for both group (negative) and DM (positive) contexts
Removed room_id from TrackedBounty - it is now just a lightweight relation/pointer; the room context lives in TrackingData
Test results:
lgtm