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

DeviceBay matching query does not exist. #6662

New Issue
Closed
opened 2025-12-29 19:43:38 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:43:38 +01:00
Owner
Copy Link

Originally created by @abhi1693 on GitHub (Jul 14, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.3.0-beta1

Python version

3.9

Steps to Reproduce

I wanted to see the changes for the cable tracing and clicked on a link from https://beta-demo.netbox.dev/dcim/interfaces/1018/ which redirected to https://beta-demo.netbox.dev/dcim/interfaces/1018/trace/

Expected Behavior

Trace page should open up

Observed Behavior

image

Originally created by @abhi1693 on GitHub (Jul 14, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.3.0-beta1 ### Python version 3.9 ### Steps to Reproduce I wanted to see the changes for the cable tracing and clicked on a link from https://beta-demo.netbox.dev/dcim/interfaces/1018/ which redirected to https://beta-demo.netbox.dev/dcim/interfaces/1018/trace/ ### Expected Behavior Trace page should open up ### Observed Behavior ![image](https://user-images.githubusercontent.com/5083532/179052876-b5dd04be-63df-41f0-904f-4629b9384ad4.png)
adam added the type: bugstatus: acceptedbeta labels 2025-12-29 19:43:38 +01:00
adam closed this issue 2025-12-29 19:43:38 +01:00
adam commented 2025-12-29 19:43:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 15, 2022):

This looks like a data migration issue. Comparing the beta demo against my local instance, the interface's cable path is exactly the same, however the content type IDs in the two databasese differ. ContentType 32 locally is dcim.interface, but on the demo it's dcim.devicebay.

The root issue is that we're copying content type IDs blindly in the database migrations. This won't affect direct upgrades, but does obviously cause an issue for transplanted data. I'll need to tweak the migration to account for changing content type IDs.

@jeremystretch commented on GitHub (Jul 15, 2022): This looks like a data migration issue. Comparing the beta demo against my local instance, the interface's cable path is exactly the same, however the content type IDs in the two databasese differ. ContentType 32 locally is `dcim.interface`, but on the demo it's `dcim.devicebay`. The root issue is that we're copying content type IDs blindly in the database migrations. This won't affect direct upgrades, but does obviously cause an issue for transplanted data. I'll need to tweak the migration to account for changing content type IDs.
adam commented 2025-12-29 19:43:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 15, 2022):

The root cause is the 0160_populate_cable_ends migration within the dcim app, which is compelling the creation of content types for the nine models which support cable termination when migrating a new database. (These are required to write generic foreign key values to the database.) This is throwing off the primary keys for these content types as compared to the static values captured in the demo data.

The ideal solution would be to return to the original order of creation for content types, though I'm not sure yet how feasible that is. The alternative approach is to alter the process for dumping the demo data to accommodate the change in content type IDs. (The simplest approach would be to switch to raw SQL dumps, although that introduces its own set of challenges.)

@jeremystretch commented on GitHub (Jul 15, 2022): The root cause is the `0160_populate_cable_ends` migration within the `dcim` app, which is compelling the creation of content types for the nine models which support cable termination when migrating a new database. (These are required to write generic foreign key values to the database.) This is throwing off the primary keys for these content types as compared to the static values captured in the demo data. The ideal solution would be to return to the original order of creation for content types, though I'm not sure yet how feasible that is. The alternative approach is to alter the process for dumping the demo data to accommodate the change in content type IDs. (The simplest approach would be to switch to raw SQL dumps, although that introduces its own set of challenges.)
adam commented 2025-12-29 19:43:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 15, 2022):

Ended up just tweaking the migration to avoid retrieving not-yet-created content types during the cable termination updates. Content types are back to normal now, which ensures compatibility with the demo data.

@jeremystretch commented on GitHub (Jul 15, 2022): Ended up just tweaking the migration to avoid retrieving not-yet-created content types during the cable termination updates. Content types are back to normal now, which ensures compatibility with the demo data.
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 beta status: accepted type: bug
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#6662
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?