You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Component
API Server / GraphQL
Describe the Feature Request
Before #4399 was fixed we had an index on the
value
property ofAttributeValue
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:
This means that those fields would never be added to an index.
Other types of fields that we might want to index include:
(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
orURL
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 largeText
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
The text was updated successfully, but these errors were encountered: