DavidCain / mitoc-trips / 223 / 1

86%

master: 86%

push

travis-ci

Start using database locks more intelligently

Also, add test coverage to affected areas of code.

A great deal of this code base does not have any mechanisms in place to
prevent updating content based off stale data.

For example:
- When editing trips, the last user to submit an update has the
  authoritative edit (we don't warn if editing on stale data)
- Long-running jobs like the Winter School lottery might have state
  change partway through their run, and have unexpected results!

We do *some* locking at the Celery level (to make that two workers
aren't accidentally running the tasks concurrently), but that's about
it. We don't make much use of database transactions, nor do we
explicitly select rows for update.

Declining to deal with concurrency was a conscious design decision.
there were fairly few users of this site (concurrency was not much of a
concern).

However, as this site grows in popularity, and the Winter School lottery
gets even bigger/hairier, we should start using locks judiciously.

578 of 1388 branches covered (41.64%)

Branch coverage included in aggregate %.

4736 of 6801 relevant lines covered (69.64%)

0.7 hits per line