point ID format

[dnalor]

I'm using MD5 sums as point IDs e.g. cfb95e0e94bcca71ca33e1dad6438c08
however, qdrant changes those to a specific form e.g. 00ab9ad0-be2f-1c72-cc75-b1856195b804
which means my system ends up using a mix of both forms (e.g. a recommendation request where the positives are in format 2, and the negatives in format 1)

• Does this have any consequence?
• Should I manually convert my IDs to qdrant's format before submitting them?
• Is the following Go code correct to convert to qdrant's format:

h := md5.New()
io.WriteString(h, URL)
m := fmt.Sprintf("%x", h.Sum(nil)) // this is what I'm using now
mq := fmt.Sprintf("%s-%s-%s-%s-%s", m[0:8], m[8:12], m[12:16],m[16:20], m[20:]) // but maybe I should use this?

[generall]

Hey @dnalor, qdrant accepts the following formats - https://qdrant.tech/documentation/concepts/points/#point-ids

Internally it is stored as integer, and original formal can't be preserved.

[timvisee]

As mentioned above, we only support numeric and UUID point IDs.

Your above md5 string is parsed as UUID, because it coincidentally has the same number of digits. I'd recommend to convert your point IDs into UUIDs on your side explicitly and use those in Qdrant, there should be no downside to this.

[dnalor]

Thanks for the replies.
The MD5 sums are generated by a 3rd party system, and I would like to avoid having to implement a mapping table between the two systems.
Mixing the two formats seems to work so far, however, depending on the answer in #5645, I'll have to switch to the hyphenated format anyway.

[timvisee]

In case of 'mapping' the MD5 hash to a UUID string on your side, you will not have to keep track of the mapping because you can freely transform it back and forward into both formats.

[dnalor]

Sorry for the confusing wording.
The "mapping" comment was meant to explain why I'm using MD5 sums in the first place.
As a result of #5645 I'm switching to using the hyphenated format for anything related to qdrant.