Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: Restrict size of common attribute kinds #4432

Closed
ogenstad opened this issue Sep 24, 2024 · 0 comments · Fixed by #4584
Closed

feature: Restrict size of common attribute kinds #4432

ogenstad opened this issue Sep 24, 2024 · 0 comments · Fixed by #4584
Assignees
Labels
type/feature New feature or request

Comments

@ogenstad
Copy link
Contributor

Component

API Server / GraphQL

Describe the Feature Request

Before #4399 was fixed we had an index on the value property of AttributeValue labels within the database. When an index is present a size limit is set in place by Neo4j preventing anything from creating an AttributeValue.value that is more than 8167 characters. This caused problems when you tried to add larger GraphQL queries as they wouldn't be accepted by the database. As a workaround we removed the index on AttributeValue.

If we want to add this type of index again we can't do so on labels that store larger amount of data within properties tied to that index. A suggested solution was to create a new label with a working name LargeAttributeValue. This could potentially require some significant changes to the query engine and it's not something that we are aiming to do at the moment. However in order to pave the way to keep that path open in the future we should limit the size of some of the types within the database.

The suggestion is that we wouldn't limit these attribute types:

  • TextArea (Which is used for GraphQLQueries
  • JSON

This means that those fields would never be added to an index.

Other types of fields that we might want to index include:

  • Text
  • URL
  • Number
  • Boolean
  • Password
  • IPHost
  • IPNetwork

(and potentially others)

Since we had this index in place for Infrahub 0.16.0 we can be fairly certain that no nodes exist in those installations today where the size of these attributes are larger than the set limit. However once we remove the index we no longer know this.

I'd suggest that we limit the fields that we might want to index in the future in order to ensure that the upgrade at that point in time is as easy as possible and we don't have users with Text or URL fields that are longer than 8167 characters. We could add a check to the validators of these functions. If we do this for version 1.0 this wouldn't be a breaking change for people upgrading from 0.16.0 but it could be problematic if anyone had installed 0.16.1 and then added a large Text attribute to a node.

In order to make the value less random perhaps we should set 4096 as the largest size for these objects. For text fields I think most people would want to use a TextArea if they have that much info regardless.

Describe the Use Case

[see above]

Additional Information

No response

@ogenstad ogenstad added the type/feature New feature or request label Sep 24, 2024
@ogenstad ogenstad added this to the Infrahub - 1.0 milestone Sep 24, 2024
@exalate-issue-sync exalate-issue-sync bot added the state/planned This issue is planned to be worked on in an upcoming release. label Oct 8, 2024
@exalate-issue-sync exalate-issue-sync bot removed the state/planned This issue is planned to be worked on in an upcoming release. label Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants