A project I work on needed a functionality of “export user and all dependent objects” (it was already needed a few years ago, but it’s also a relatively easy way to comply with the GDPR requirement to allow a user to get all the data you keep on them). So, instead of writing code listing specific models, which would then need to be maintained every time a model is added, we wrote something generic – used
django.db.models.deletion.Collector to collect the objects and then dump them as JSON, et voila. We did need to use the Collector, a private API, directly, but we mostly just needed to use it.
But now we’ve encountered a problem with the approach – we started using
on_delete=PROTECT on FKs, and that broke the collection; since the Collector assumes objects are collected for deletion, when it encounters objects related through such a FK, it cries foul.
This check in the collector – invoking and acting upon decisions of the
on_delete parameter – is hardwired into its
collect() method; so in order to make it do what I wanted, I had no choice but to override it with an almost-exact copy.
So, I would like to start a discussion about doing at least one of two things –
- Defining the export functionality mentioned above important enough to be supported by a pubic API, or,
- Making the current collector a little more modular, so that a user could collect objects not just for deletion
Opinions and ideas welcome.