lets add unit tests as well. I'd like to see if its possible to track the same bounty multiple times. if possible, should we handle the logic here or somewhere else?
can we store both of the data under data folder instead of separating them?
don't we need unit tests for this services? in a way to make sure that everything we defined in this service are working as expected even if with faulty input
Conclusion: ensure_room() and ensure_tracking() are NOT needed as public Protocol methods.
I think we should remove ensure_room() and ensure_tracking() then since its adding unnecessary…
can we add a test where we have a very simple mock storage to check or verify if we really need an ensure_room function? basically the goal is to see do we need the ensure_room() or we can safely remove it and expect things also works without it.
why do we need personal storage when we now doesnt really separate which one is personal and which one is group? I think its somehow already covered in the tracking storage and room storage.
what…
I think we should rename it into room_id to make it works and makes sense for both group and DM
we can remove room_id from here since TrackedBounty is just a relation, while we store the actual data in the TrackingData
I dont understand the difference of TrackingData and TrackedBounty. when to use which?
since 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
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
created_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