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

Enable PostgreSQL full text searching #5218

New Issue
Closed
opened 2025-12-29 19:25:33 +01:00 by adam · 13 comments
adam commented 2025-12-29 19:25:33 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Aug 23, 2021).

NetBox version

v2.11.11

Feature type

New functionality

Proposed functionality

Extend NetBox's search functionality to employ PostgreSQL's native full text search capability. This is already supported by Django: https://docs.djangoproject.com/en/3.2/ref/contrib/postgres/search/

I haven't dug into this too much yet, but it appears to be pretty straightforward. I expect the bulk of the work will involve replacing our sets of filter() parameters with SearchQuery and SearchVector instances, and adding a common SearchVectorField to all appropriate models.

I'm also open to alternative strategies for improving NetBox's global search performance, however any such proposals should be opened as separate feature requests and referenced here.

Use case

This change should provide much more robust search functionality, and allow us to rank search results according to customizable rankings per model.

Database changes

We'll likely need to add a new SearchVectorField to each searchable model.

External dependencies

No response

Originally created by @jeremystretch on GitHub (Aug 23, 2021). ### NetBox version v2.11.11 ### Feature type New functionality ### Proposed functionality Extend NetBox's search functionality to employ PostgreSQL's native full text search capability. This is already supported by Django: https://docs.djangoproject.com/en/3.2/ref/contrib/postgres/search/ I haven't dug into this too much yet, but it appears to be pretty straightforward. I expect the bulk of the work will involve replacing our sets of `filter()` parameters with `SearchQuery` and `SearchVector` instances, and adding a common `SearchVectorField` to all appropriate models. I'm also open to alternative strategies for improving NetBox's global search performance, however any such proposals should be opened as separate feature requests and referenced here. ### Use case This change should provide much more robust search functionality, and allow us to rank search results according to customizable rankings per model. ### Database changes We'll likely need to add a new SearchVectorField to each searchable model. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:25:33 +01:00
adam closed this issue 2025-12-29 19:25:33 +01:00
adam commented 2025-12-29 19:25:34 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 7, 2021):

Would this enable global searching based off of any object fields? That would be a great feature to have to find things that we might not know the name of 100%

@ghost commented on GitHub (Oct 7, 2021): Would this enable global searching based off of any object fields? That would be a great feature to have to find things that we might not know the name of 100%
adam commented 2025-12-29 19:25:34 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 4, 2022):

Would this enable global searching based off of any object fields? That would be a great feature to have to find things that we might not know the name of 100%

Including MAC addresses. :-)

@ghost commented on GitHub (Jan 4, 2022): > Would this enable global searching based off of any object fields? That would be a great feature to have to find things that we might not know the name of 100% Including MAC addresses. :-)
adam commented 2025-12-29 19:25:34 +01:00
Author
Owner
Copy Link

@hagbarddenstore commented on GitHub (Jan 17, 2022):

From the plugin framework workgroup:

Be able to add models defined in plugins to the global / full text search capabilities mentioned here.

@hagbarddenstore commented on GitHub (Jan 17, 2022): From the plugin framework workgroup: Be able to add models defined in plugins to the global / full text search capabilities mentioned here.
adam commented 2025-12-29 19:25:35 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (May 13, 2022):

Looking forward to v3.3 with this full-text search !

@PieterL75 commented on GitHub (May 13, 2022): Looking forward to v3.3 with this full-text search !
adam commented 2025-12-29 19:25:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 2, 2022):

Unfortunately it doesn't look like we'll be able to tackle this in v3.3 without additional help. A lot of work is still needed to determine exactly how this should be implemented, and any overlap with a future indexer (yet to be determined) must be evaluated.

@jeremystretch commented on GitHub (Jun 2, 2022): Unfortunately it doesn't look like we'll be able to tackle this in v3.3 without additional help. A lot of work is still needed to determine exactly how this should be implemented, and any overlap with a future indexer (yet to be determined) must be evaluated.
adam commented 2025-12-29 19:25:35 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jun 2, 2022):

Is there a way to introduce a wildcard in the search as an alternative? So that we can do switch00 or devsw ?
This is really one of the biggest remarks I get from new users that migrate from our old cmdb

@PieterL75 commented on GitHub (Jun 2, 2022): Is there a way to introduce a wildcard in the search as an alternative? So that we can do *switch00* or dev*sw* ? This is really one of the biggest remarks I get from new users that migrate from our old cmdb
adam commented 2025-12-29 19:25:35 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 2, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 2, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:25:35 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Aug 10, 2022):

Would it be possible to sponsor this as a feature?

@ITJamie commented on GitHub (Aug 10, 2022): Would it be possible to sponsor this as a feature?
adam commented 2025-12-29 19:25:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 11, 2022):

@ITJamie we don't allow direct sponsorship of features in NetBox, however you're certainly welcome to compensate individuals who want to help explore the feasibility of this proposal and perhaps develop a proof of concept.

@jeremystretch commented on GitHub (Aug 11, 2022): @ITJamie we don't allow direct sponsorship of features in NetBox, however you're certainly welcome to compensate individuals who want to help explore the feasibility of this proposal and perhaps develop a proof of concept.
adam commented 2025-12-29 19:25:36 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Aug 26, 2022):

Dug into this more:

  1. watson - is tailored to a title-description-content search which I'm not sure really maps to what NetBox needs. But does offer a multi-model search and does a lot of the work for you.
  2. Django Postgres search - more flexible, would need to replicate some of what watson is doing, also watson probably would be easier for plugin search unless we replicate some of the model-registration stuff (probably a good idea).
  3. Current NetBox search does partial word match (icontains) so if you search "kron" it will match "Akron" - postgresql search (and watson) can only do prefix search (so only startswith) it won't find a partial string embedded in another. So this would potentially break functionality that someone might use?
  4. Doing things like searching device by ipaddress is doable, we just need to explicitly define these as searchable combos. PostgreSQL search we would need to specifically define them, watson looks like you have a middleware that would follow the FK but bloating out the search index.
  5. Watson would be quicker to implement but less adaptable and might not be a perfect fit. PostgreSQL would require more work (replicating some of watson stuff).
  6. Trigram stuff would allow embedded character search, similar search, etc... but requires the PostgreSQL extension so is probably a no-go.
  7. Also can make it do "ipam:xxx" to search a specific model type, also found stuff to do more complicated google type searches if needed (- to exclude stuff, and or queries, etc...)
@arthanson commented on GitHub (Aug 26, 2022): Dug into this more: 1. watson - is tailored to a title-description-content search which I'm not sure really maps to what NetBox needs. But does offer a multi-model search and does a lot of the work for you. 2. Django Postgres search - more flexible, would need to replicate some of what watson is doing, also watson probably would be easier for plugin search unless we replicate some of the model-registration stuff (probably a good idea). 3. Current NetBox search does partial word match (icontains) so if you search "kron" it will match "Akron" - postgresql search (and watson) can only do prefix search (so only startswith) it won't find a partial string embedded in another. So this would potentially break functionality that someone might use? 4. Doing things like searching device by ipaddress is doable, we just need to explicitly define these as searchable combos. PostgreSQL search we would need to specifically define them, watson looks like you have a middleware that would follow the FK but bloating out the search index. 5. Watson would be quicker to implement but less adaptable and might not be a perfect fit. PostgreSQL would require more work (replicating some of watson stuff). 6. Trigram stuff would allow embedded character search, similar search, etc... but requires the PostgreSQL extension so is probably a no-go. 7. Also can make it do "ipam:xxx" to search a specific model type, also found stuff to do more complicated google type searches if needed (- to exclude stuff, and or queries, etc...)
adam commented 2025-12-29 19:25:36 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 26, 2022):

  • Current NetBox search does partial word match (icontains) so if you search "kron" it will match "Akron" - postgresql search (and watson) can only do prefix search (so only startswith) it won't find a partial string embedded in another. So this would potentially break functionality that someone might use?

I suspect we would want to find a way to keep icontains, as I imagine a lot of people rely on it.

@DanSheps commented on GitHub (Aug 26, 2022): > * Current NetBox search does partial word match (icontains) so if you search "kron" it will match "Akron" - postgresql search (and watson) can only do prefix search (so only startswith) it won't find a partial string embedded in another. So this would potentially break functionality that someone might use? I suspect we would want to find a way to keep icontains, as I imagine a lot of people rely on it.
adam commented 2025-12-29 19:25:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 27, 2022):

Marking this as temporarily blocked by #8927. At this point we still intend to implement this for v3.4.

@jeremystretch commented on GitHub (Sep 27, 2022): Marking this as temporarily blocked by #8927. At this point we still intend to implement this for v3.4.
adam commented 2025-12-29 19:25:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 4, 2022):

I'm going to close this out in favor of an alternate implementation detailed in #10560, which I expect to be considerably more robust. This issue will be retained for reference in the event the other proposal proves untenable.

@jeremystretch commented on GitHub (Oct 4, 2022): I'm going to close this out in favor of an alternate implementation detailed in #10560, which I expect to be considerably more robust. This issue will be retained for reference in the event the other proposal proves untenable.
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 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#5218
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?