starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Introduce object change migrators #11248

New Issue
Closed
opened 2025-12-29 21:42:26 +01:00 by adam · 0 comments
adam commented 2025-12-29 21:42:26 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Jun 2, 2025).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v4.3.1

Feature type

New functionality

Proposed functionality

Extend certain data migrations within NetBox to include migration functions for updating changelog data. This is an experimental initiative to provide improved support for complex migration operations performed by plugins (i.e. netbox-branching) and potential future use cases.

For example, the ipam.0071_prefix_scope migration includes a RunPython() operation which copies data from the legacy site field to the new scope_type & scope_id fields. This effectively handles the database schema migration, however it does not provide any mechanism for adapting changelog records that were created prior to the migration being applied.

The proposed implementation established a convention where a migration can be extended to include a dictionary named objectchange_migrators and mapping object types to functions that can be called to "translate" older changelog data to a format compatible with the post-migration model. An example for the ipam.0071_prefix_scope migration is included below.

def oc_prefix_scope(objectchange, revert):
    site_ct = ContentType.objects.get_by_natural_key('dcim', 'site').pk
    for data in (objectchange.prechange_data, objectchange.postchange_data):
        if data is None:
            continue
        if site_id := data.get('site'):
            data.update({
                'scope_type': site_ct,
                'scope_id': site_id,
            })
        data.pop('site')


objectchange_migrators = {
    'ipam.prefix': oc_prefix_scope,
}

Use case

This work is primarily being driven by work on the netbox-branching plugin, specifically to support applying schema migrations within a branch. However, it is being implemented in a way that both keeps the adaptation logic close to its associated schema migration and decouples the functionality from any specific third party consumer. It's possible that we may find additional uses for such an adaptation mechanism in the future.

The immediate goals of this proposal to prove viability of this approach and to establish a lightweight convention. This is not yet intended to become a public API. If proven successful, we will document and publish the refined implementation in a future release.

Database changes

N/A

External dependencies

N/A

Originally created by @jeremystretch on GitHub (Jun 2, 2025). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v4.3.1 ### Feature type New functionality ### Proposed functionality Extend certain data migrations within NetBox to include migration functions for updating changelog data. This is an experimental initiative to provide improved support for complex migration operations performed by plugins (i.e. [netbox-branching](https://github.com/netboxlabs/netbox-branching)) and potential future use cases. For example, the [`ipam.0071_prefix_scope`](https://github.com/netbox-community/netbox/blob/main/netbox/ipam/migrations/0071_prefix_scope.py) migration includes a `RunPython()` operation which copies data from the legacy `site` field to the new `scope_type` & `scope_id` fields. This effectively handles the database schema migration, however it does not provide any mechanism for adapting changelog records that were created prior to the migration being applied. The proposed implementation established a convention where a migration can be extended to include a dictionary named `objectchange_migrators` and mapping object types to functions that can be called to "translate" older changelog data to a format compatible with the post-migration model. An example for the `ipam.0071_prefix_scope` migration is included below. ```python def oc_prefix_scope(objectchange, revert): site_ct = ContentType.objects.get_by_natural_key('dcim', 'site').pk for data in (objectchange.prechange_data, objectchange.postchange_data): if data is None: continue if site_id := data.get('site'): data.update({ 'scope_type': site_ct, 'scope_id': site_id, }) data.pop('site') objectchange_migrators = { 'ipam.prefix': oc_prefix_scope, } ``` ### Use case This work is primarily being driven by work on the [netbox-branching]() plugin, specifically to support [applying schema migrations within a branch](https://github.com/netboxlabs/netbox-branching/issues/1). However, it is being implemented in a way that both keeps the adaptation logic close to its associated schema migration and decouples the functionality from any specific third party consumer. It's possible that we may find additional uses for such an adaptation mechanism in the future. The immediate goals of this proposal to prove viability of this approach and to establish a lightweight convention. This is not yet intended to become a public API. If proven successful, we will document and publish the refined implementation in a future release. ### Database changes N/A ### External dependencies N/A
adam added the status: acceptedtype: featurecomplexity: medium labels 2025-12-29 21:42:26 +01:00
adam closed this issue 2025-12-29 21:42:27 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: medium status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11248
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?