RomanNum3ral
/
netbox
mirror of https://github.com/netbox-community/netbox.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Apply batched suggestions from code review 

Co-authored-by: Jason Novinger <jnovinger@gmail.com>
This commit is contained in:
Jeremy Stretch 2026-09-15 14:08:26 -04:00 committed by GitHub
parent 002e8de1be
commit e941535407
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 14 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/administration/repairing-hierarchical-paths.md
View File

@ -28,8 +28,13 @@ python netbox/manage.py rebuild_ltree_paths --check
The same test can be run as SQL against a deployment which has not yet been upgraded. Substitute each hierarchical table in turn: `dcim_region`, `dcim_sitegroup`, `dcim_location`, `dcim_devicerole`, `dcim_platform`, `dcim_modulebay`, `dcim_inventoryitem`, `dcim_inventoryitemtemplate`, `tenancy_tenantgroup`, `tenancy_contactgroup`, and `wireless_wirelesslangroup`.
```no-highlight
SELECT count(*) FROM dcim_region c JOIN dcim_region p ON c.parent_id = p.id
WHERE c.path <> p.path || lpad(c.id::text, 19, '0')::ltree;
SELECT count(*) FROM (
SELECT id FROM dcim_region WHERE parent_id IS NULL
AND path <> lpad(id::text, 19, '0')::ltree
UNION ALL
SELECT c.id FROM dcim_region c JOIN dcim_region p ON c.parent_id = p.id
WHERE c.path <> p.path || lpad(c.id::text, 19, '0')::ltree
) x;
```
Treat any non-zero result as "this table needs rebuilding" rather than as a count of the damage: an object whose ancestor moved is reported, but its own descendants are consistent with it and so are not, even though they are equally stale.
@ -39,8 +44,12 @@ Treat any non-zero result as "this table needs rebuilding" rather than as a coun
The nine tables which order their children by name additionally maintain a `sort_path`, which can go stale on a rename even when `path` is correct. Every table in the list above except `dcim_inventoryitem` and `dcim_inventoryitemtemplate` carries one, and is checked with:
```no-highlight
SELECT count(*) FROM dcim_region c JOIN dcim_region p ON c.parent_id = p.id
WHERE c.sort_path <> p.sort_path || chr(9) || c.name;
SELECT count(*) FROM (
SELECT id FROM dcim_region WHERE parent_id IS NULL AND sort_path <> name
UNION ALL
SELECT c.id FROM dcim_region c JOIN dcim_region p ON c.parent_id = p.id
WHERE c.sort_path <> p.sort_path || chr(9) || c.name
) x;
```
Stale `sort_path` values affect only the order in which objects are listed. A stale `path`, by contrast, misplaces an object within the hierarchy, so it can be omitted from its ancestor's list of descendants.

2
docs/release-notes/version-4.7.md
View File

@ -3,7 +3,7 @@
## v4.7.1 (2026-09-15)
!!! warning "Databases Restored From a v4.7.0 Dump"
The triggers which cascade a hierarchical object's path to its descendants could not be recreated when restoring a `pg_dump` of a v4.7.0 database, so such a restore reported success while leaving the database without those triggers. Renaming or moving a region, site group, location, device role, platform, tenant group, contact group, wireless LAN group, module bay, or inventory item then did not update its descendants. Upgrading reinstalls the triggers so that all subsequent changes cascade correctly, but does **not** repair values which have already gone stale. See [Repairing Hierarchical Paths](../administration/repairing-hierarchical-paths.md) for how to detect and correct them, and for the steps plugins maintaining their own `ltree` models must take.
The triggers which cascade a hierarchical object's path to its descendants could not be recreated when restoring a `pg_dump` of a v4.7.0 database, so such a restore reported success while leaving the database without those triggers. Renaming or moving a region, site group, location, device role, platform, tenant group, contact group, wireless LAN group, module bay, inventory item, or inventory item template then did not update its descendants. Upgrading reinstalls the triggers so that all subsequent changes cascade correctly, but does **not** repair values which have already gone stale. See [Repairing Hierarchical Paths](../administration/repairing-hierarchical-paths.md) for how to detect and correct them, and for the steps plugins maintaining their own `ltree` models must take.
### Enhancements