Often you want to give the user the ability to delete objects but enable them to recover them if they change their mind.

One way to do this is to have a boolean flag on the model. The problem with this is

you have to have the flag on all associated models involved in the object graph to be deleted

you have to then filter all your queries based on that boolean flag (error prone and inefficient)

An alternative is to have a separate model for the deleted objects. i.e. DeletedFoo alongside Foo, DeletedBar alongside Bar. The schemas are similar (although some foreign keys are to their deleted counterparts instead) and objects are moved from one table to another when deleted (or undeleted).

This has certain advantages over the first approach, but does mean you have to create twice as many models.

A third approach which just occurred to me is to serialize the object graph to be deleted and store that in the database in a single table row. With Django's existing ability to calculate object graphs for deletion and also to load and dump json, this may be fairly straightforward to implement in a generic fashion.

Pinax is currently using the first approach but I'm interested if people have tried the third approach or secret option number four I don't know about yet.