fle-internal/ka-lite-central — pull request #118 by bcipolli (2014-04-12 21:40:12+00:00)
Title: Implement record "deletion" (deletion stub++)

This is a very risky PR; the purposes to post here are:

* To get feedback on the design and direction
* To encourage the development of automated sync tests
* To show that this isn't that hard--this is 5 hours of work.

So, right now lots of things are held up because we don't allow data deletion. We have a bunch of crappy data, people aren't satisfied with their data displays (because it has a bunch of undeletable test data), and overall things are rigid. Of all the feedback we get, asking about deleting objects is one of the most frequent.

I've implemented data "deletions" in the following way:

* Deleted data exist as before--just with the `deleted` field set to `True`
* The default `manager` for querying out data simply filters out objects with `deleted=True`
* A secondary `manager`, used for syncing purposes, doesn't contain that filter.
* When an objects is "deleted", all objects using it as a foreign key are also "deleted" (just like Django does).
* I disabled the **actual** delete functionality, just for kicks (and because we don't define system state if this actually happens!).
* I provide back-door entry hooks (via `settings`) for showing "deleted" data and ACTUALLY deleting objects.

The Python tips and tricks to do this also allowed me to remove the `add_syncing_models` call at the bottom of each `models.py` file, and does this automatically for any `SyncedModel` subclass. Now we're talking!

Testing:

* Right now our distributed server interface only enables deleting `Facility` objects. So, I created facilities, ran `generaterealdata`, etc. to see that I could delete through the interface
* I tested through `shell_plus` to check that **actual** deletion throws an error.
* I ran syncing tests. Since `deleted` is a field that triggers syncing (nice job @jamalex!), both deleted and non-deleted objects sync.

Notes:

* This isn't a deletion stub, nor am I convinced that we ever want one. These are full records--just a method to hide them. That way, deletion is reversible, and good data that others may want to delete we can use for our own purposes (whatever they may be).