Defer change logging until all changes have been applied #435

New Issue

MrUnknownDE · 2026-04-05T16:32:36+02:00

MrUnknownDE commented

2026-04-05 16:32:36 +02:00

Originally created by @jeremystretch on 1/31/2026

NetBox Version

v4.5.1

Python Version

3.12

Area(s) of Concern

User Interface
REST API
GraphQL API
Python ORM
Other

Details

Currently, an ObjectChange record is created in the database immediately after save() is called on an applicable model. This results in each record being created individually even for bulk operations.

We should enqueue the creation of change records until all changes have been successfully applied, and write them to the database via a single bulk operation immediately prior to the transaction being committed. This optimizes the creation of change records into a single bulk SQL INSERT.

We'll need to identify a solution which leverages a queue when changes are made in the context of a request, but retains the current synchronous behavior (via post_save) otherwise.

While it would be feasible to defer the creation of change records to an async background task, we should keep them constrained to the same database transaction in which the changes are applied. This ensures that the both the application and logging of a change to an object are atomic.

*Originally created by @jeremystretch on 1/31/2026* ### NetBox Version v4.5.1 ### Python Version 3.12 ### Area(s) of Concern - [x] User Interface - [x] REST API - [ ] GraphQL API - [ ] Python ORM - [ ] Other ### Details Currently, an ObjectChange record is created in the database immediately after `save()` is called on an applicable model. This results in each record being created individually even for bulk operations. We should enqueue the creation of change records until all changes have been successfully applied, and write them to the database via a single bulk operation immediately prior to the transaction being committed. This optimizes the creation of change records into a single bulk SQL `INSERT`. We'll need to identify a solution which leverages a queue when changes are made in the context of a request, but retains the current synchronous behavior (via `post_save`) otherwise. While it would be feasible to defer the creation of change records to an async background task, we should keep them constrained to the same database transaction in which the changes are applied. This ensures that the both the application and logging of a change to an object are atomic.

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance type: performance

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#435