Schema/API Design comments (Hunter Lathery)

[hlathery]

1. For the ER diagram, Roommate going to chore assignment is currently: One or many roommates are assigned to one or no chore_assignments. Doesn’t it make sense to have a roommate able to be assigned to multiple chores. So rather: One or many roommates are assigned to none, one or many chores.

2. Same situation with Roommate and Bill_List. One or many roommates could have none, one or many bills

3. In API spec 1. Create Chore, it currently says create chore will assign it to a roommate, when you are only just creating the chore itself for any roommate to see. So maybe just remove the “assign to roommate” in the description

4. Possibly add a no-repeat to your “frequency” enum, for one time chores that wouldn’t require repeating.

5. There is a chores assignment POST, and a GET chores, currently it looks like there are only safety checks to make sure a roommate isn't assigned the same chore as another, but there's no way to see an assigned list of chores for yourself or another roommate.

6. Currently almost all except a priority variable are assigned as bigints. Certain columns such as roommate_id and others that you believe would be logical to lower to a smaller int to reduce file size. Only thinking for when we will insert a million rows of data would probably make a decent size difference. Same with double precision float8 -> float4 for things that make sense.

7. Would make sense to add the ability to remove a roommate, for if someone moves out, especially since bills divide by total roommates and if you have a roommate that isn’t there anymore you will have money still left to pay on it.

8. Missing ability to see the status of chores , currently only 'completed' chores are available to see in chore history. Maybe add status to get chores

9. Similar to above but chores and bills both have their PATCH statement which runs through the /assignments, however it doesn't seem as though there is currently an assignments table, only two separate attributes on the chore_assignments and bill_list table.

10. Inside your schema for table chore_assignment, you are adding the constraint that status be either 'pending', 'in_progress', or 'completed'. This is good but it should also be a check in user input, as currently you can just put anything other than that as a string, and you will get a internal server error.

11. Certain columns are allowed to be null in your schema when they should never be null, eg: bill_list has bill_id and roommate_id as null when they should never be. Verify other columns in other tables and make sure they make sense as null or not.

12. Consider adding functionality for adding custom bill_types , or lessening strictness on the bill enum type. For example what if a user wants to split a cable bill with their roommates, or streaming services, etc.

[s6hib]

1. The current schema supports a roommate having multiple chore assignments.

2. A roommate can be associated with zero, one, or many bills through the bill_list table.

3. Changed API Spec to remove the part that it assigns to a roomate.

4. Modified the frequency_enum definition to include 'no-repeat'

5. The existing GET /chores endpoint already provides all chore information.

6. Changed instances of biginit to int.

7. Implemented an endpoint to remove roomates.

8. You can see the status when you assign a chore, update it, and like Hunter said you can view all completed chores already.

9. Separate tables for chores and bills (chore_assignments and bill_list) are better than a unified table as they preserve clear domain separation for their distinct attributes and statuses.

10. We added a drop down where those are your only options.

11. Now specified certain columns where they can not be nullable.

12. Great suggestion that we can implement in the future. As of right now, we cover almost all extremely common bills that almost everyone has with the drop down option, so we won't be missing out on much.