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

Using a different character to "/" in node ids. #20765

Closed
Kafkalasch opened this issue Mar 19, 2024 · 3 comments
Closed

Using a different character to "/" in node ids. #20765

Kafkalasch opened this issue Mar 19, 2024 · 3 comments

Comments

@Kafkalasch
Copy link

My Environment

  • ArangoDB Version: 3.10.6

Problem:
Hi, I was wondering if there is any way of disallowing the usage of "/" in the id of nodes. The current format is /. The issue is, that many APIs use the ids as part of the url path.

e.g. /orders/{orderId}

If we want to use that API, this results in /orders/mycollection/123 which usually breaks the api as the slash is interpreted as part of the url path and not as part of the id.

Obviously there are workarounds but they can become quite nasty if many systems are involved.

Is there a way to configure which character the database uses for the ids? If one could configure that the ids should look like - or something like that, it would already help a lot.

@jsteemann
Copy link
Contributor

@Kafkalasch : there is no option available to configure the character that is used to separate the collection name part and the key part in ArangoDB document ids. The character is hard-coded to /, and many components in ArangoDB rely on this character. So I think it is safe to assume that it will stay this way for the foreseeable future.

In order to use a document id in URLs, it will need to be URL-encoded, e.g. /orders/mycollection/123 would become /orders/%2f123 or such. This does not only apply to the forward slash, but also to some other punctuation characters which could be used in URLs.
There is also the possibility of doing the replacement of forward slashes with some other character in the client application, and decoding it on the server-side if custom receiving APIs are built on the server side. If the latter is not the case, then it is of course not an option.

@Kafkalasch
Copy link
Author

thank you for the fast response. I already expected something like this but thought I'd ask just to be sure =)

@dothebart
Copy link
Contributor

please remember that there may be more characters worth the effort of URL encoding.
Will close this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants