Schema/API Design comments Gibson Hooper

[gibsonhooper25]

1. I don't see the time_sign_up Users attribute being used anywhere other than the get_user() endpoint, if it's not being used anywhere in the future it can probably be deleted.
2. The User class says user_type is a string but the ER diagram says it's an integer.
3. Performers and Venues should be able to have multiple time slots available (many pairs of time_available and time_end). This would allow for some search endpoint where a performer could search for a venue that is available for any one of that performer's available times. It would require a table containing a foreign key reference to a performer or venue id (maybe one table for each) and a pair of time_available and time_end values.
4. capacity_preference should not just be a minimum value. It should either be a range (capacity_preference_max and capacity_preference_min attributes) or there should be a buffer where the capacity is allowed to be within a certain range of the capacity preference.
5. The spec for /catalog/performers says it retrieves the list of "all available performers", but in the actual code it seems to just return a list of all performers (it doesn't check for availability).
6. Instead of performers and venues creating bookings directly, consider having a request/approval system. In book endpoints, add the booking request to a new requests table that holds info about the requested booking (user_id, time, venue, etc). Then, the performer or venue that was booked unknowingly should be able to access a list of requests, and be able to accept or reject these requests. The request is added to the bookings table only if it is accepted by both performer and venue.
7. Return more informative messages in POST calls: for example, a message explaining why a book/create/request was unsuccessful (time did not match, etc) instead of just {"success: false"}
8. There should be better location information - maybe a state and city (attributes in Venues). Then there could be a location_preference attribute within Performers. A simple implementation could be a state attribute in Performers where they are only matched with venues in that state. A more complex implementation could be venues having a latitude and longitude, and Performers have a max_distance attribute and are only matched with venues where they are within that distance of the given venue.
9. Since there is a price attribute for Venues, you could include other payment features, such as tracking how much money a User has and/or how much they are willing to pay for a performance.
10. Bookings could have a 1:1 mapping with a Performances table. Performances could hold info like revenue, attendance, and ratings. This way you can keep track of what Performers and Venues are making the most money, etc.
11. I don't see a reason for restricting the integer ranges of values like performer_id, capacity_preference, and price. There is no validation for these in the signup endpoint and there's no reason (that I can think of) to limit how many Users there are.
12. As an additional feature, you could allow multiple Performers for the same booking. The main code change required for this is inserting one entry for each performer into the Bookings table.
13. I don't understand how user_id maps to performer_id or venue_id. It seems like Performers and Venues should have a user_id attribute as a foreign key, and this is being inserted in the signup endpoint (INSERT INTO performers (name, capacity_preference, price, user_id)), but the schema.sql does not show a user_id for either Performers or VEnues table.
14. The ER diagram for Performers is not accurate. When I do a GET for all performers it returns values with a price attribute which is not specified as an attribute for Performers.