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

Increase all field lengths to a "modern" minimum #8256

New Issue
Closed
opened 2025-12-29 20:34:23 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:34:23 +01:00
Owner
Copy Link

Originally created by @jwbensley on GitHub (Jun 27, 2023).

NetBox version

v3.4.3

Feature type

Data model extension

Proposed functionality

At various points in the past requests have come in to increase the length of a field, for example:

We keep hitting various character limits in Netbox, and keep having to hack in solutions to work around them. For example we have site's and the facility name is longer than the 50 char limit. We have tenants who's name is longer than 100 chars.

Is it possible to just wholesale change the text field sizes everywhere in NetBox (for any name or description) which are less than 256 characters to be at least 256 characters (round to a whole byte)?

Use case

We are hitting the character limits on fields with low character limits.

It's 2023, the amount of storage space that we are talking about, which is required to store this information is a drop in the ocean these days. We aren't saving any storage space with these low character limits and we are just having to add complexity and hacks to work around this.

Whatever new minimum is agreed upon could also become the default minimum for new fields added, unless something larger is specified?

Database changes

No idea.

External dependencies

No idea.

Originally created by @jwbensley on GitHub (Jun 27, 2023). ### NetBox version v3.4.3 ### Feature type Data model extension ### Proposed functionality At various points in the past requests have come in to increase the length of a field, for example: - https://github.com/netbox-community/netbox/issues/4817 - https://github.com/netbox-community/netbox/issues/3249 - https://github.com/netbox-community/netbox/issues/11573 - https://github.com/netbox-community/netbox/issues/6349 - https://github.com/netbox-community/netbox/issues/5822 We keep hitting various character limits in Netbox, and keep having to hack in solutions to work around them. For example we have site's and the facility name is longer than the 50 char limit. We have tenants who's name is longer than 100 chars. Is it possible to just wholesale change the text field sizes everywhere in NetBox (for any name or description) which are less than 256 characters to be at least 256 characters (round to a whole byte)? ### Use case We are hitting the character limits on fields with low character limits. It's 2023, the amount of storage space that we are talking about, which is required to store this information is a drop in the ocean these days. We aren't saving any storage space with these low character limits and we are just having to add complexity and hacks to work around this. Whatever new minimum is agreed upon could also become the default minimum for new fields added, unless something larger is specified? ### Database changes No idea. ### External dependencies No idea.
adam added the type: featurestatus: revisions needed labels 2025-12-29 20:34:23 +01:00
adam closed this issue 2025-12-29 20:34:23 +01:00
adam commented 2025-12-29 20:34:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 27, 2023):

The character limits are not there to save space; they are in place to help mitigate the misuse of fields for unintended purposes. If you're routinely running into these limits, you're likely attempting to store data not intended for the fields. A common example is people trying to cram all manner of detail into interface descriptions, rather than using purpose-built (or custom) fields for structured data.

Is it possible to just wholesale change the text field sizes everywhere in NetBox (for any name or description) which are less than 256 characters to be at least 256 characters (round to a whole byte)?

This is not something we would consider. If you'd like to propose increasing the maximum length of specific fields, please modify your proposal above to name each model and field, and cite a specific use case for each.

@jeremystretch commented on GitHub (Jun 27, 2023): The character limits are not there to save space; they are in place to help mitigate the misuse of fields for unintended purposes. If you're routinely running into these limits, you're likely attempting to store data not intended for the fields. A common example is people trying to cram all manner of detail into interface descriptions, rather than using purpose-built (or custom) fields for structured data. > Is it possible to just wholesale change the text field sizes everywhere in NetBox (for any name or description) which are less than 256 characters to be at least 256 characters (round to a whole byte)? This is not something we would consider. If you'd like to propose increasing the maximum length of **specific fields**, please modify your proposal above to name each model and field, and cite a specific use case for each.
adam commented 2025-12-29 20:34:23 +01:00
Author
Owner
Copy Link

@stuntguy3000 commented on GitHub (Jun 28, 2023):

Could we support user configurable text field lengths?

@stuntguy3000 commented on GitHub (Jun 28, 2023): Could we support user configurable text field lengths?
adam commented 2025-12-29 20:34:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 28, 2023):

Could we support user configurable text field lengths?

No; these are baked into the database schema.

@jeremystretch commented on GitHub (Jun 28, 2023): > Could we support user configurable text field lengths? No; these are baked into the database schema.
adam commented 2025-12-29 20:34:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 10, 2023):

Closing this as there's no further action needed.

@jeremystretch commented on GitHub (Jul 10, 2023): Closing this as there's no further action needed.
adam commented 2025-12-29 20:34:24 +01:00
Author
Owner
Copy Link

@jwbensley commented on GitHub (Jul 13, 2023):

The character limits are not there to save space; they are in place to help mitigate the misuse of fields for unintended purposes. If you're routinely running into these limits, you're likely attempting to store data not intended for the fields. A common example is people trying to cram all manner of detail into interface descriptions, rather than using purpose-built (or custom) fields for structured data.

Sorry for the delay @jeremystretch .

You response raises a couple of questions:

  1. If fields have intended purposes, where is this documented, how can I know the purpose of the field?

I said:

For example we have site's and the facility name is longer than the 50 char limit. We have tenants who's name is longer than 100 chars.

So if storing the facility name in the facility field of a site is not the correct place to store that information, then the field names are misleading and some documentation is needed on where the correct place to store this information is.

  1. I still don't see how this is justification for such short field lengths, or why they can't be extended: If you're routinely running into these limits, you're likely attempting to store data not intended for the fields.

If the name of a facility is longer than the 50 character limit, there is nothing I can do about that. I don't create these name, the data centre operators do. In our case, sites are automatically added to NetBox from another system which doesn't have these field length limitations. So I think this field misuse reason needs to be better explain, I am failing to see the logic.

@jwbensley commented on GitHub (Jul 13, 2023): > The character limits are not there to save space; they are in place to help mitigate the misuse of fields for unintended purposes. If you're routinely running into these limits, you're likely attempting to store data not intended for the fields. A common example is people trying to cram all manner of detail into interface descriptions, rather than using purpose-built (or custom) fields for structured data. Sorry for the delay @jeremystretch . You response raises a couple of questions: 1. If fields have intended purposes, where is this documented, how can I know the purpose of the field? I said: `For example we have site's and the facility name is longer than the 50 char limit. We have tenants who's name is longer than 100 chars.` So if storing the facility name in the `facility` field of a site is not the correct place to store that information, then the field names are misleading and some documentation is needed on where the correct place to store this information is. 2. I still don't see how this is justification for such short field lengths, or why they can't be extended: `If you're routinely running into these limits, you're likely attempting to store data not intended for the fields.` If the name of a facility is longer than the 50 character limit, there is nothing I can do about that. I don't create these name, the data centre operators do. In our case, sites are automatically added to NetBox from another system which doesn't have these field length limitations. So I think this field misuse reason needs to be better explain, I am failing to see the logic.
adam commented 2025-12-29 20:34:24 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 13, 2023):

Jeremy isn't saying that we cannot raise the limits of some of the fields. He is saying that there needs to be some justification behind them instead of just wholesale changing the field lengths. Providing specific examples is ideal (for example, a facility name that doesn't conform).

For now, if you wish to have facility name increased, please open a FR specifically for that field with the justification for it. Same with Tenant.

@DanSheps commented on GitHub (Jul 13, 2023): Jeremy isn't saying that we cannot raise the limits of some of the fields. He is saying that there needs to be some justification behind them instead of just wholesale changing the field lengths. Providing specific examples is ideal (for example, a facility name that doesn't conform). For now, if you wish to have facility name increased, please open a FR specifically for that field with the justification for it. Same with Tenant.
adam commented 2025-12-29 20:34:24 +01:00
Author
Owner
Copy Link

@hagbarddenstore commented on GitHub (Jul 31, 2023):

I've created #13316 to handle Tenant and Tenant Group name limits.

@hagbarddenstore commented on GitHub (Jul 31, 2023): I've created #13316 to handle Tenant and Tenant Group name limits.
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 status: revisions needed 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#8256
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?