[Fix] Laundry Rewrite to Account For New SpeedQueen API #308
Conversation
|
Currently fails all tests because tests are written on a mock of the old API, will have to rewrite (or maybe we just test it live?) >:) |
dr-Jess
requested review from
tuneerroy and
vcai122
and removed request for
tuneerroy
sorry kiddo, gotta write the tests before we deploy :) |
| @@ -5,18 +5,18 @@ | |||
|
|
|||
|
|
|||
| class LaundryRoom(models.Model): | |||
There was a problem hiding this comment.
Can you explain why previously we had a hall_id and why we have a room_id now?
What is the difference between them?
Depending on this answer, I may be hesitant to delete UUID.
There was a problem hiding this comment.
hall_id was just a generic id/pkey (0, 1, 2...) on our end. UUID was a specific id that was used to access the room from an end point.
The new API has a more relational structure, where there's a one to many between locations and rooms. To keep track of this, we need to store both.
Have you tested this manually? I think it wouldn't be too much of a lift to mock the new one? It should be just in a couple places right? |
There was a problem hiding this comment.
HE DID IT!!!!!!! 6 shots
left most of my questions throughout
couple notes for READABILITY
- indexes are EVIL
- compute stuff seperately if it makes it more clear (don't jam everything in the same for loop this is not a leetcode problem, but also you shouldn't be solving ur leetcode problems that way anyway)
- similar to above don't feel the need to be ultra efficient by only doing 1 for loop. Readability is number 1 concern
Rewrite laundry to handle Penn's new SpeedQueen API, without changing anything that would affect the frontend. Future plans are to hard rewrite (new API has more data, such as whether a machine door is open/could be used to tell when laundry hasn't been taken out!!!), but this is a quick fix.
Some notes on the new API:
Statuses are entirely reworked, but I've left the possible options as the old ones and lined them up best I can as to not break the frontend.
Additionally, the API is now actually relational!! with locations and rooms instead of a page to be scraped. This means we'll have to properly track both locations and the rooms in them now, modifying our requests to match this pattern.