Maddie & Anibel - VideoStoreAPI - Edges

[anibelamerica]

Video Store API

Congratulations! You're submitting your assignment!
If you didn't get to the functionality the question is asking about, reply with what you would have done if you had completed it.

Comprehension Questions

Question	Answer	Feedback
Explain how you came up with the design of your ERD, based on the seed data.	We looked at the seed data to get an idea for the keys in our ERD. Otherwise, the design behind the ERD was based off the prompt.
What would be the Big-O time complexity of your /customers & /movies endpoints? What does the time complexity depend on? Explain your reasoning.	The time complexity of the /movies endpoint is O(n) where n is the number of movie records in the database since we are retrieving all movies. The time complexity of /customers is at best-case scenario O(n) if no order is required. Otherwise, the time complexity will be based on active record's .order method and will depend on the database's implementation O(n) or worse.	This is not quite correct. First, you need to define n - is this the number of customers/movies, the number of rentals, or something else? Second, since .order sorts the data, we know it is at best O(c log(c)), where c is the number of customers. Third, when you generate JSON for a customer, you call the movies_checked_out_count method, which means the time depends on the time to find the rentals for that customer - probably O(log(r)) where r is the total number of rentals, depending on how the database index is built. Then the total time would be O(c log(r) + c log(c))
What is the Big-O time complexity of the POST /rentals/check-in endpoint? What does the time complexity depend on? Explain your reasoning.	The time complexity of the POST /rentals/check-in endpoint is restricted by the finding the record in the db and saving it. Assuming that find queries to active record databases are modeled like a hash table, this endpoint should run in O(1) time.	That's a pretty big assumption, especially since your call to find_by is checking a number of properties. Usually databases use trees for indexed fields (movie_id, customer_id), and have to resort to linear search for unindexed fields (checked_out?). The database will do the faster filters first, which means you end up with something slightly worse than O(log(r)), where r is the number of rentals.
Describe a set of positive and negative test cases you implemented for a model.	For example, the Customer model had a positive case to check if a customer was successfully created with valid parameters provided. The negative test case checked to see that a customer was not created with invalid or missing parameters.
Describe a set of positive and negative test cases you implemented for a controller.	For example, the Movie controller's show action had a positive case to test if the endpoint returned JSON with the expected fields and a success status. The negative test case checked that it returned a JSON with the error messages and a not_found status.
How does your API respond when bad data is sent to it?	Our API sends back in a JSON format with an error message and an appropriate status.
Describe one of your custom model methods and why you chose to wrap that functionality into a method.	We have an available_inventory Movie method that returns the available inventory for an instance of a movie. We wrapped this functionality in a method since it made our controller code more readable and could also be used in our .rabl views.
Do you have any recommendations on how we could improve this project for the next cohort?	The rabl gem was a little confusing so perhaps 30 minutes introducing this gem in the context of our projects would be helpful (in addition to rails cast).
Link to Trello	https://trello.com/b/1nIp4Fwk
Link to ERD	https://www.lucidchart.com/invitations/accept/b6fdd5d9-0918-44c8-be4e-b02ae4350aa3
Summary	APIs are cool. We worked on balancing both within our own work and as a team. It was great!

[droberts-sea]

Video Store

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene	yes
Comprehension questions	yes - see feedback inline around complexity. The database makes this problem much more complicated, so don't worry if your answer wasn't quite right.
General
Business Logic in Models	yes - good work!
All required endpoints return expected JSON data	yes - good use of rabl
Requests respond with appropriate HTTP Status Code	yes
Errors are reported	yes
Testing
Passes all Smoke Tests	yes
Model Tests - all relations, validations, and custom functions test positive & negative cases	yes
Controller Tests - URI parameters and data in the request body have positive & negative cases	yes - good coverage and organization (not retesting the details of Rental#overdue? in the tests for the RentalsController, for example)
Overall	Great work overall! This code is well-organized, well-tested, and does a good job of solving the problem at hand. It is clear to me that the learning goals for this assignment were met. Keep up the hard work!