Currently, the id of a document, or call it the handle/anchor/whatever, is an object. This way everything we think that might be useful for document identification can be put inside.
For now in practice there is only one property inside, an actual id, called GUID. For simplicity this id is generated from an incrementing counter, so it ends to be a number.
This is probably not the best solution, since we could imagine changing it in the future to a hash, formatted as an hexadecimal string for instance. In this case it would be a string.
For consistency and anticipation this should be changed to a string starting from now.
Moreover, this might lead to some issues with some clients of the backend, since with the serialization process and the diversity of the libraries used for it, the number could be parsed as a float number, giving unwanted results when converting to a string.
Indeed, the backend already converts the id to a string (implicitly) to access the document from an index.
Imagine the following scenario:
an id is generated on the backend side: 10_(backend id)_
the backend uses the string representation of this id to store a document in the index: "10"_(backend key)_
the id is serialized and sent as an integer to the client: 10_(backend to client id)_
the client uses a library which doesn't make the distinction between integer and float numbers, and parses everything as floats, it would give: 10.0_(client id)_
the client sends back the serialized id for a service request: 10.0_(client to backend id)_
the backend receives it and parses it as a float this time: 10.0_(backend id)_
it tries to retreive the document as it did the first time to store oit, using the string representation: "10.0"_(backend key)_ :arrow_right: FAIL
We've passed from the stringified integer "10" to a stringified float number "10.0".
Currently, the id of a document, or call it the handle/anchor/whatever, is an object. This way everything we think that might be useful for document identification can be put inside.
For now in practice there is only one property inside, an actual id, called
GUID. For simplicity this id is generated from an incrementing counter, so it ends to be a number.This is probably not the best solution, since we could imagine changing it in the future to a hash, formatted as an hexadecimal string for instance. In this case it would be a string.
For consistency and anticipation this should be changed to a string starting from now.
Moreover, this might lead to some issues with some clients of the backend, since with the serialization process and the diversity of the libraries used for it, the number could be parsed as a float number, giving unwanted results when converting to a string.
Indeed, the backend already converts the id to a string (implicitly) to access the document from an index.
Imagine the following scenario:
10_(backend id)_"10"_(backend key)_10_(backend to client id)_10.0_(client id)_10.0_(client to backend id)_10.0_(backend id)_"10.0"_(backend key)_ :arrow_right: FAILWe've passed from the stringified integer
"10"to a stringified float number"10.0".