Schema-update

[Soyokaze-42]

This updates the current backend reflecting many of the changes we discussed. I still have one outstanding question: do we want to keep PrayerDecks for history of when a prayerdeck was created, how many cards were in in, and that sort of thing like we want to keep a log of all the times a userprayercard has been prayed.

I also changed some of the urls to make them friendlier (the root of the app is "" instead of "/cardbox").

While I was looking at the templates, I updated them to have a base template so we can see the debug toolbar and put a shell out there for you guys to expand.

[asherlloyd]

@Soyokaze-42 perhaps each DB entity could inherit from a BaseEntity structure that includes such info as

• creator (id)
• created (datetime)
• updated (datetime)
• deleted (datetime) For each table that needs it, the above seems sufficient for record keeping. Thoughts @kenancasey?

[kenancasey]

I like having those fields for basic auditing/logging. Not sure how expensive this would be but it seems relatively cheap. I'm in favor of it.

[Soyokaze-42]

Deleted would be problematic because the row we would be storing the field on is the row we would be deleting. I could probably create an auditlog table of everything that was deleted if we need that.

Created and updated dates are cheap. They are automatic fields on the model.

created_by and updated_by will be more work to update them appropriately. I'll see what I can do.

[kenancasey]

I don't know what the conventions are, but I can imagine that if you wanted to support soft delete, you could add a timestamp to the deleted column when you deleted it but leave it null otherwise and only return rows with null in the deleted column whenever you ran a query. For this version 1, though that seems like overkill.

[Soyokaze-42]

I've updated this PR with a few changes after talking to @kenancasey. Considering the Prayer Deck as something the user will only ever have one of, I moved the prayer deck fields into the usercard and the userprofile and removed the prayerdeck and prayerdeckusercard tables. Now the prayer_deck_updated_date is in the profile since I already had a one to one relationship with the user there and data-wise it fits fine. The prayerdeckusercards are denoted by the bool in_prayer_deck on the usercard. If the card is currently in the deck, that will be true.

[Soyokaze-42]

If we want to do soft delete, we should consider that a different feature to see how we want it to work. It would not be too hard to add it, but we would have to write some policy like how long should it stay in the db before we clean it up (or leave it forever?)

As far as created/modified information, take a look at what it takes to add it in Django in 5e3ebf8 and tell me if you think the benefits of doing it are worth the added complexity to the code. Are we are thinking it would be good to know for troubleshooting? We will also have plenty of cases where the created_by and modified_by fields are blank. I don't think that is a problem, it may be a surprise, though.