Introduce object change migrators

[jeremystretch]

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