search

charm-13 / petcafe

https://cute-creature-cafe.onrender.com
0 stars 0 forks source link

Schema/API Design Comments-Adam Cisneros #13

Open Adam-Cisneros opened 2 days ago

Adam-Cisneros commented 2 days ago
  1. The users_treat_inventory table referenced in creatures.py for the feed_creture function is not in the schema.sql file.
  2. Instead of having fav_treat and hated_treat just be plain text, you could have them as foreign keys to the treats table so that those values are not as hard-coded
  3. You could also just have the name of the treat be the primary key instead of the sku because it looks like most of the skus and names are the same if not similar as it would reduce the amount of data held and simplify the table a bit
  4. Have the name just be the primary key to creature_types as it seems to uniquely identify each column and it is what is being referenced to from foreign keys from other tables.
  5. In the set up for the creatures table it seems you already have default values set up for happiness, health, and hunger, but are not using them. I do not know if you want these default values to be the starting values but, if you do, then do not specify those columns in the insert into command.
  6. For many of the id columns you have it set up so that they are generated by default so do not specify them in the insert into command as they will generate for you and it will simplify the sql statement
  7. The name column in the creatures table seems to uniquely identify each row and it is the column referenced to by most foreign keys from other tables, so just make that the primary key for the table.
  8. I think it would be sufficient if your ids in your tables were regular, smaller integers rather than bigints
  9. In the API spec, I would have the sku in the CartItem class as well as allowing a list of CArtItems to be passed in just to simplify the function of adding items to a cart and so that it may only be called once.
  10. Instead of having success booleans, such as play_success and feed_success, passed to the user, you could just throw errors to warn the user that doing this action would be pointless.
  11. The sku and the name of each treat seem to be the same if not similar so it may not be necessary to display both to the user when they call the GET catalog function
  12. Delete user should be a POST I believe instead of specifying it as a DELETE as our classifications are mainly PUT, POST, or GET.