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

Batch IP Address Record Update #2042

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

Originally created by @branbot3000 on GitHub (Oct 3, 2018).

Environment

  • Python version: 3.7
  • NetBox version: 2.4.5

Proposed Functionality

Enable enhanced REST functionality -
specifically, add PATCH method for HTTP interactions.
image

Use Case

This specific use case proposes that a feature be added that would allow batch updates to IP address records. For example, in this instance I would be utilizing the REST API to edit several thousand of them at once - updating their description fields to contain their hostnames.

The benefit of this feature would be increased ease of use. I work for a company with thousands of end users and this would greatly increase efficiency when recording updates to our network environment. We recently switched to your IPAM system and are missing host names as a result of human error during our initial data migration. I have been working around this through scripting but it's been a chore, and it seems like this enhancement wouldn't necessarily be something too difficult to implement on your end, but I could be wrong. Let me know what you think!

Originally created by @branbot3000 on GitHub (Oct 3, 2018). ### Environment * Python version: 3.7 * NetBox version: 2.4.5 ### Proposed Functionality Enable enhanced REST functionality - specifically, add PATCH method for HTTP interactions. ![image](https://user-images.githubusercontent.com/43684815/46379655-5cb94b80-c654-11e8-9dc2-f9b44868dc75.png) ### Use Case This specific use case proposes that a feature be added that would allow batch updates to IP address records. For example, in this instance I would be utilizing the REST API to edit several thousand of them at once - updating their description fields to contain their hostnames. The benefit of this feature would be increased ease of use. I work for a company with thousands of end users and this would greatly increase efficiency when recording updates to our network environment. We recently switched to your IPAM system and are missing host names as a result of human error during our initial data migration. I have been working around this through scripting but it's been a chore, and it seems like this enhancement wouldn't necessarily be something too difficult to implement on your end, but I could be wrong. Let me know what you think!
adam closed this issue 2025-12-29 17:21:42 +01:00
adam commented 2025-12-29 17:21:43 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 4, 2018):

Don't forget you can do INSERTs and UPDATEs directly on the underlying postgres database. It's well-structured and there is referential integrity. Obviously you need to be careful not to do silly things which the web interface or API would prevent.

There is a risk that creeping changes can turn a RESTI API into an unholy chimera. For a perfect example of this take a look at Salesforce:

That's not even scratching the surface - "a mess" doesn't even start to describe it. So be careful what you wish for :-)

@candlerb commented on GitHub (Oct 4, 2018): Don't forget you can do INSERTs and UPDATEs directly on the underlying postgres database. It's well-structured and there is referential integrity. Obviously you need to be careful not to do silly things which the web interface or API would prevent. There is a risk that creeping changes can turn a RESTI API into an unholy chimera. For a perfect example of this take a look at [Salesforce](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_what_is_rest_api.htm): * [Composite collections create API](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_sobjects_collections_create.htm) to add multiple unrelated objects, with or without transactional (all-or-nothing) semantics * [Composite tree API](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_composite_sobject_tree_create.htm) for inserting multiple related objects - but only root objects of the same type * [Composite collections delete API](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_sobjects_collections_delete.htm) * [Batch API](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_batch.htm) for submitting mixed batches of arbitrary REST calls (but no transactional semantics) * [Bulk API](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm) for asynchronous background processing of large batches of inserts/upserts/deletes etc * [Queries](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_query.htm) over REST in [two different SQL-like query languages](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) * A whole bunch of [arbitrary limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_soslsoql.htm) That's not even scratching the surface - "a mess" doesn't even start to describe it. So be careful what you wish for :-)
adam commented 2025-12-29 17:21:43 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Oct 5, 2018):

That's one more spot where GraphQL would shine. But it's most probably never going to happen. See #2007

@cimnine commented on GitHub (Oct 5, 2018): That's one more spot where GraphQL would shine. But it's most probably never going to happen. See #2007
adam commented 2025-12-29 17:21:43 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 5, 2018):

GraphQL looks cool. I guess you would create Mutations to allow the batch updates the OP was asking for.

Then all you have to do is rewrite the UI in Javascript to talk to GraphQL, and you have re-implemented the whole application :-)

@candlerb commented on GitHub (Oct 5, 2018): GraphQL looks cool. I guess you would create Mutations to allow the batch updates the OP was asking for. Then all you have to do is rewrite the UI in Javascript to talk to GraphQL, and you have re-implemented the whole application :-)
adam commented 2025-12-29 17:21:43 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Oct 5, 2018):

Then all you have to do is rewrite the UI in Javascript to talk to GraphQL, and you have re-implemented the whole application :-)

It would indeed be useful for this: One request to fetch all information required to render the content.

(This gets OT.)

@cimnine commented on GitHub (Oct 5, 2018): > Then all you have to do is rewrite the UI in Javascript to talk to GraphQL, and you have re-implemented the whole application :-) It would indeed be useful for this: One request to fetch all information required to render the content. (This gets OT.)
adam commented 2025-12-29 17:21:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 6, 2018):

NetBox employs the Django REST Framework (a third-party extension to the Django framework) for its API. I don't believe this functionality is currently supported by DRF. There was some work done on an external package called django-rest-framework-bulk but it is no longer maintained and almost certainly incompatible with recent releases. We can revisit this if support is introduced in DRF, but it's probably not something we want to tackle directly.

Regarding your specific use case, it is inadvisable to record hostnames in the description field of IP addresses: The device name is already accessible at ipaddress.interface.device. But if you really want to, you can easily perform one-off bulk updates using the local Python console (./manage.py nbshell). Something like this should work:

for ip in IPAddress.objects.select_related('interface__device').filter(address__net_host_contained='10.0.0.0/8'):
    if ip.interface and ip.interface.device:
        ip.description = ip.interface.device.name[:100]
        ip.save()
@jeremystretch commented on GitHub (Nov 6, 2018): NetBox employs the [Django REST Framework](https://www.django-rest-framework.org/) (a third-party extension to the Django framework) for its API. I don't believe this functionality is currently supported by DRF. There was some work done on an external package called [django-rest-framework-bulk](https://github.com/miki725/django-rest-framework-bulk) but it is no longer maintained and almost certainly incompatible with recent releases. We can revisit this if support is introduced in DRF, but it's probably not something we want to tackle directly. Regarding your specific use case, it is inadvisable to record hostnames in the description field of IP addresses: The device name is already accessible at `ipaddress.interface.device`. But if you really want to, you can easily perform one-off bulk updates using the local Python console (`./manage.py nbshell`). Something like this should work: ``` for ip in IPAddress.objects.select_related('interface__device').filter(address__net_host_contained='10.0.0.0/8'): if ip.interface and ip.interface.device: ip.description = ip.interface.device.name[:100] ip.save() ```
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
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#2042
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?