Deleting media and annotations

When media, localizations, states, or leaves are deleted via the REST API or web interface, the database records and associated files are actually held for one month by default. Instead, the deleted flag is marked as True in the database for all affected objects, and those objects are then excluded from queries. This is done for two reasons: to mitigate accidental deletions, and to enable fast deletion through the REST API. After a month passes since an object was marked for deletion, a Kubernetes CronJob is run to actually remove objects from the database. For media, when a media database object is deleted, the reference counter on the Resource object corresponding to each file is decremented. If the reference count goes to zero (i.e. all media clones that use the file are deleted) the Resource object is deleted, and then the media files are also deleted in object storage.

Recovering deleted objects

If you need to restore objects that were deleted prior to their permanent deletion, you can reset the deleted flag to False using the django shell:

>>> from main.util import Media
>>> recover = Media.objects.filter(project=PROJECT_ID, deleted=True)
>>> recover.update(deleted=False)

Forcing deletion

If you need to delete files or database objects prior to the 30 day grace period, you can invoke the python management command directly. From the tator source directory:

make gunicorn-bash
python3 manage.py prunemedia --min_age_days=0 # Force delete media
python3 manage.py prunelocalizations --min_age_days=0 # Force delete localizations
python3 manage.py prunestates --min_age_days=0 # Force delete states
python3 manage.py pruneleaves --min_age_days=0 # Force delete media