Guarantee relational data integrity

[mattyg]

I would like to see our "business logic" assumptions about the data models enforced more robustly at the database + ORM layer. It seems the task of verifying these assumptions is bleeding throughout the application, rather than being enforced at the data + orm layer (i.e. before the "business logic" of the application touches any data).

Currently we're at greater risk of our data reaching a "dirty" state -- where the assumptions made about it throughout the application are no longer correct. We also have an increased workload and mental overhead for developers trying to reason about the application behavior.

Overview

• Explicit data relation between praise, period, and quantification. Currently there are several places where to praise is logically associated with a period. Refactor data model -- make 'quantifications' it's own collection #322
• Use of db transactions. With db transactions we could execute a bunch of database queries together, and revert them all if any fail. Ensuring that we never reach a "dirty" data state from a partially completed transaction. Mongodb supports transactions only when using replica sets (i.e. 2-3 servers configured as a replica set).
• Update / deletion cascading
• Consider moving data relations from ORM layer to database layer. With mongodb having no support for relations, and mongoose picking up that slack on the ORM layer, we still run the risk of "dirty" data from direct changes to the database, or mongoose quirks / limitations.

Issues where this has appeared

• https://github.com/commonsbuild/praise_frontend/issues/101