qdrant
Accept 64bit integers as strings for javascript clients? Discuss.
Is your feature request related to a problem? Please describe. I generated 64 bit integers for ids for my collection points, as strings we're not supported (related: #610 ) I was able to create the collection fine using a python client.
When I tried to query my points using nodejs, i get the problem that i need to generate ids that are technically 'out of spec' for JSON
Some other services (https://developers.google.com/discovery/v1/type-format#:~:text=For%20example%2C%20a%2064%2Dbit,string%20in%20JSON%20requests%2Fresponses.) allow using strings instead to side-step this problem. Recent versions of javascript support Bigint, but apparently when serializing to JSON, this also goes to a string.
Describe the solution you'd like
If i try to serialize the id as a string, i get this: "response": {"result":null,"status":{"error":"Json deserialize error: data did not match any variant of untagged enum ExtendedPointId at line 1 column 30"},"time":0}
Maybe it's easy enough to coherse it to an 64 bit int on the server side?
Describe alternatives you've considered a) Support other payload encodings besides JSON, as JSON spec does not support 64 bit integers officially. b) clearly state the limitation in the docs. (not ideal but a start)
Here's a bit more about the difficulty of the topic: https://stackoverflow.com/questions/60842629/how-to-serialize-64-bit-integer-in-javascript
About a). Looks like using gRPC would work on nodejs would work. https://grpc.io/docs/languages/node/basics/
Alternatively, you could also use UUID, there is a direct conversion between i64 and uuid. But I would agree that automatic parsing of string as integers might be useful. I can only think about one disadvantage - you won't get ID in the same format as you uploaded it.
Alternatively, you could also use UUID, there is a direct conversion between i64 and uuid.
I don't understand what you mean. UUIDs are 128 bit values in my book.
yes, and if you originally have 64 bit integers, you can easily convert them into uuid.
Do you mean to say, that for a point with id 6763074405716742595 for example , i should fetch with uuid: 00000000000000005ddb4456f64851c3 ? By that i mean zero-pad it?
The interface does take the UUIDs, but in my case if fails to find the point.
The interface does take the UUIDs, but in my case if fails to find the point.
Do you mean that point saved with id = 00000000000000005ddb4456f64851c3 is not available in http://localhost:6333/collecions/<collection>/points/00000000000000005ddb4456f64851c3 ?
No. i saved the point as a i64 as '6763074405716742595'. I can't retrieve it using the numerically equivalent uuid. This is expected, but the wording of your comment indicated to me that it was possible.
My problem is still that i essentially have a database full of points that are irretrievable using a javascript client.
in my case, i think the simplest solution is to run a migration to UUIDs.