Refactor Models; address poss. deletions of dependencies?

[sandrockjustin]

We have a bit of a problem here and for a few reasons. The first thing is that we can't just delete a user...first we would have to delete all other records that are using the current user as a foreign key. If we don't do this, the database operation fails.

This introduces a new problem, however...if I delete a user's records then their game records are deleted too...this means that players would suddenly no longer have some "wins" on their records with our current implementation.

Current hypothesis is that we can delete most user data from the database such as the following:

• friend associations
• cards associated with a deck // we actually can't delete these because Rounds && Games depend on them
• decks themselves // same here
• then we can delete the cards

With the previous notes in mind, maybe we just preserve the user_id but delete personal information?

• Change the display name to something like "deleted user"
• Change the googleID to null so they can't login to this account anymore
• Remove the email associated with the account so they can sign up again with that email

The only thing we need to figure out is how we can make these nullable, given that some of the prior constraints are unique.

[sandrockjustin]

Additional consideration; a User Deck is submitted for a game right now so that we can track what deck they decided to bring into the game. This presents a similar issue, because technically a user can delete one of their card decks. A brief overview of the issue:

1. I bring a card deck into a Game; it is tracked for quite a few reasons here.

   • It offers some anti-cheat functionality, preventing users from changing their deck mid-game.
   • It enables us to enforce a consistent deck for that Game session, and track which cards have been played already.
   • It enables us to generate a Round and provide a "card played" for that round, so that we can determine the status of the game and players on the next round.

2. Theoretically, let's say that the game has concluded and the other player one. I did not like anything in the deck that I used during that game, so I have decided that I am going to delete the entire deck.

3. Let's say that I actually did delete that card deck from my account...well now that Game session has been broken because the card deck it saved on record no longer exists. Similarly, Rounds are now broken because they are referencing cards from my card deck (which no longer exists).

I think that there are a few ways we can go about this.

Least Desirable Option: Any time that a deck is modified (card added, card deleted, deck deleted) we create a copy in the database. This seems like it would just pollute the database with useless data.

Most Desirable Option: Sever connections and relationships when/where possible. When a game is created, we submit a selected_deck property from the user and store an array of cards (a copy of the current card deck) for that game on the Games table. In this case there is no association or relationship that is maintained between the data and where it originally came from. Then, in the Rounds table, we use this copy of data to reference outward to the Cards table (which should always be consistent since items are not deleted, but only ever archived).