Should be tackled in notifications-api-common (partially) - but the interaction is definitely relevant.
We now have Audit trail, notification and cache mixins/decorators that all operate on the viewset action serializer (instance). Often these mixins query the involved object and/or construct a fresh serializer instance. Serializing each of these instances of the same serializer class results in bad query performance because it repeats queries that were done already, especially to serialize the response data.
This whole mixin approach needs to be revisited for a better/more granular approach giving more control for re-use of instances that can leverage their own caches, so that performance is maximized without dirty tricks.
Additionally, the @transaction.atomic behaviour should either be configurable or managed in the downstream project - now often mixins create stacks of savepoints/savepoint releases that introduce unnecessary query IO.
Should be tackled in notifications-api-common (partially) - but the interaction is definitely relevant.
We now have Audit trail, notification and cache mixins/decorators that all operate on the viewset action serializer (instance). Often these mixins query the involved object and/or construct a fresh serializer instance. Serializing each of these instances of the same serializer class results in bad query performance because it repeats queries that were done already, especially to serialize the response data.
This whole mixin approach needs to be revisited for a better/more granular approach giving more control for re-use of instances that can leverage their own caches, so that performance is maximized without dirty tricks.
Additionally, the
@transaction.atomicbehaviour should either be configurable or managed in the downstream project - now often mixins create stacks of savepoints/savepoint releases that introduce unnecessary query IO.