Queue changelog objects for deletion events the same as creates/updates #2828

Closed
opened 2025-12-29 18:22:33 +01:00 by adam · 0 comments
Owner

Originally created by @jeremystretch on GitHub (Aug 26, 2019).

Proposed Changes

Currently, ObjectChanges which represent object creations/updates are queued up during a request and saved to the database (by ObjectChangeMiddleware) only after the request completes. ObjectChanges for deletion events, however, are written immediately. This is because the serialized representation of a deleted object must be generated prior to any related objects being deleted.

This issue seeks to queue deletion ObjectChanges in the same manner as the others. This should be doable by tweaking all log_change() methods to return a new ObjectChange for queuing rather than creating it immediately. Then, we can simply queue up the unsaved ObjectChanges (each of which contains a serialized representation of its respective object) to be written to the database once the request completes.

Justification

By not logging any ObjectChanges until after a request completes, we provide a more sensible behavior and simpler rollback for scenarios where database transactions need to be rolled back.

Originally created by @jeremystretch on GitHub (Aug 26, 2019). ### Proposed Changes Currently, ObjectChanges which represent object creations/updates are queued up during a request and saved to the database (by ObjectChangeMiddleware) only after the request completes. ObjectChanges for deletion events, however, are written immediately. This is because the serialized representation of a deleted object must be generated prior to any related objects being deleted. This issue seeks to queue deletion ObjectChanges in the same manner as the others. This should be doable by tweaking all `log_change()` methods to return a new ObjectChange for queuing rather than creating it immediately. Then, we can simply queue up the unsaved ObjectChanges (each of which contains a serialized representation of its respective object) to be written to the database once the request completes. ### Justification By not logging any ObjectChanges until after a request completes, we provide a more sensible behavior and simpler rollback for scenarios where database transactions need to be rolled back.
adam added the status: acceptedtype: housekeeping labels 2025-12-29 18:22:33 +01:00
adam closed this issue 2025-12-29 18:22:33 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2828