Open Brich96 opened 2 years ago
Dont want to step on your toes @ted-tanner. noticed you already added the model to start tracking this. I need to add a route for downloading a game and updating its download count and the logic for this will be very similar. Happy to leave it for you as you have already done half the work though.
You are welcome to edit the models freely. You won't be stepping on my toes. I'd hardly classify creating the models as the "hard part."
I mostly created the models as a simple outline for what needed to be done.
This sounds to me like a many-to-many relationship. In a relational SQL database, this is normally done by creating a separate record for each relationship, then using a single query to filter on one ID contained and join on another ID contained in the relationship record.
For example, relating a user to a favorited game would entail creating a record containing a
user_id
and agame_id
. Here is an example of a query that would fetch a list of the user's favorite games ({user_id}
is a variable):This is done so the models for users and games don't have to be changed to support favorites. Additionally, if the users model simply had a list of favorite games, synchronization issues would arise when two request handlers running on different threads request a list of the favorites, make a change (like to add or remove a favorite from the list), then submit the new list to be saved in the database. One of the lists changes will be overwritten in this case.
The solution we use with Firestore (and Mongo) needs to account for the same considerations as the many-to-many scheme with relational SQL databases. This likely means creating a table or type in the database that contains the IDs of objects from two different tables.