-
Notifications
You must be signed in to change notification settings - Fork 400
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
Since there seems to be special requirements for label name, it would be nice to extend a function to verify name correctness #1911
Labels
enhancement
New request
Comments
@MironAtHome That should be easy to add. |
jrgemignani
added a commit
to jrgemignani/age
that referenced
this issue
Jun 13, 2024
Added the function is_valid_label_name (apache#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
@MironAtHome This is pending review of #1912, but will add that functionality. |
rafsun42
pushed a commit
that referenced
this issue
Jun 14, 2024
Added the function is_valid_label_name (#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
jrgemignani
added a commit
to jrgemignani/age
that referenced
this issue
Jun 14, 2024
Added the function is_valid_label_name (apache#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
jrgemignani
added a commit
to jrgemignani/age
that referenced
this issue
Jun 14, 2024
Added the function is_valid_label_name (apache#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
jrgemignani
added a commit
to jrgemignani/age
that referenced
this issue
Jun 14, 2024
Added the function is_valid_label_name (apache#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
jrgemignani
added a commit
to jrgemignani/age
that referenced
this issue
Jun 15, 2024
Added the function is_valid_label_name (apache#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
@MironAtHome This change is in the master branch, pending reviews for the lower branches. I should point out that the graph and label names follow the standards set by Neo4j. |
MuhammadTahaNaveed
pushed a commit
that referenced
this issue
Jun 17, 2024
Added the function is_valid_label_name (#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
MuhammadTahaNaveed
pushed a commit
that referenced
this issue
Jun 17, 2024
Added the function is_valid_label_name (#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
MuhammadTahaNaveed
pushed a commit
that referenced
this issue
Jun 17, 2024
Added the function is_valid_label_name (#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
MuhammadTahaNaveed
pushed a commit
that referenced
this issue
Jun 17, 2024
Added the function is_valid_label_name (#1911) per user request. This function will return a boolean value for any agtype string passed, depending on whether it is a valid name for a label. For all other types, not an agtype string, it will error out. Depending on user requirements, this could be changed in the future. Added regression tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am currently about to convert large set of semi - structured data saved in files into somewhat winning combination of flexible data structure and yet stable enough reporting architecture.
However, I am running into naming convention conflicts between how files named shards of information and what label name Age graph database can support.
Rather than having hundreds of failures, during "create" function call, it would make sense if same function(s) used to validate label name internally and produce an error message "ERROR: label name is invalid " had a function that verifies name and produces boolean output, to inform myself, that I need to add additional name transcription step in function that normalizes file content naming towards graph database labels.
It would also be very nice if age extended some kind of standardized v_label_name(?) normalization function. Though postgres native quote_ident is not par, but it's something to have in mind, as an idea.
Something like this
age_quote_ident('AgeIdentityName')
age_normalize_ident('AgeUnfriendlyIdentityName#')
age_verify_ident('AgeUnfriendlyIdentityName#')
I would like to take an escape clause, the above is not an intent or ask. Just laying out where I am at and asking for an eye to look and weight what is the most appropriate step. It would make sense to add tooling, if team wishes to keep naming of label's the way it is, or, if team so plans ahead, make label name aligned with general postgres identity naming convention. Either approach is equally great on my mind.
The text was updated successfully, but these errors were encountered: