6 ms·

We moved away from UUIDs for different reasons. It is hard to work with UUIDs when multiple entities have them. You do not know if you are looking at a user or

We moved away from UUIDs for different reasons. It is hard to work with UUIDs when multiple entities have them. You do not know if you are looking at a user or a group if both is just a UUID. We created our own IDs with prefixes and using base58 encoding for the random part, for example: user-AhnPpn7CbbwPykmux11LJ39Jk. It has the same amount of randomness in it and we can understand what we are looking at.

DJBunnies 6y ago
Uuid v5 is namespaced.
- skissane 6y ago
  But given a v3 or v5 UUID, you can’t tell what namespace it belongs to. Both are one way functions from (namespace,name) -> uuid. The gp is asking for a way to tell user uuid apart from group uuid just by looking at the uuid. That is actually possible with the v2 uuids used with DCE. But, since just about nobody uses DCE any more, just about nobody uses v2 uuids either
  - pbronez 6y ago
    What is DCE?
    - skissane 6y ago
      https://en.m.wikipedia.org/wiki/Distributed_Computing_Environment https://en.m.wikipedia.org/wiki/Distributed_Computing_Enviro...
globular-toast 6y ago
Why would you ever be in a situation where you have a UUID but don't know what it refers to?
- seppel 6y ago
  * You stumble upon them in log files or error messages. * Somebody asks you why some API call is not working. * You send around Excel files to higher management (for example in incidents).
  - globular-toast 6y ago
    Now I'm even more baffled. What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies? Why would you need to communicate uuids to higher management? This makes me think of Douglas Adams. You know the answer is 42 but you forgot what the question was. I really can't imagine how this could ever happen in a business. "Yes, sir, there was a problem with 1087." "1087 what?" "I don't know, but it was number 1087."
    - kube-system 6y ago
      I can think of a lot of reasons why it might happen. Maybe you have a process accepts multiple types of objects. Maybe you think you are passing in the correct type of object but you are not. Maybe the person reporting the error to you omitted information. Maybe the person who wrote the application didn't log enough context. Yes, all of these situations are not ideal, but if the process was ideal you wouldn't be debugging it in the first place. > I really can't imagine how this could ever happen in a business. "Yes, sir, there was a problem with 1087." "1087 what?" "I don't know, but it was number 1087." This happens all the time in many businesses. Users rarely generate perfect error reports, and it's not uncommon for intermediaries to incorrectly communicate details either. What developer hasn't seen an error report that consists of a vague screenshot with "doesn't work, got this error" as the description?
      - globular-toast 6y ago
        > Users rarely generate perfect error reports, and it's not uncommon for intermediaries to incorrectly communicate details either. What developer hasn't seen an error report that consists of a screenshot with "doesn't work, got this error" as the description? And the solution is to have them repeat a UUID to you? I don't think so...
SigmundA 6y ago
looks like its almost twice the size of a UUID at 30 bytes in this case with a short prefix, I'm assuming your storing this as a ascii string? That's a lot of extra bytes from some convenience when viewing logs or raw data etc. UUID's stored properly in binary form are only 16 bytes which can still be a concern over an 8 or 4 byte integer when you have a lot of them all over the place in a large db. (larger index more memory use).
- StreamBright 6y ago
  You can store UUIDs as bytes if you wish but when you are looking at it in a human readable form it will be still a UUID. I think storing UUID as text in 2021 is not that hard. >> UUID's stored properly in binary form are only 16 bytes Depending on what is your use case.
  - SigmundA 6y ago
    >> You can store UUIDs as bytes if you wish but when you are looking at it in a human readable form it will be still a UUID. I think storing UUID as text in 2021 is not that hard. Not going to store a text type prefix + UUID in a 16byte UUID column, you will need a variable length text column. All your DB tools will convert UUID to human readable plus the column name no need to store in the data reading for every value. if your looking at network traffic or debugging the id will hopefully be keyed (json, query string, protobuf, etc) if your looking at plain text logs with no schema, sure emit the type-UUID for readability, in your logging code... >>Depending on what is your use case. Only use case I can think of is unstructured logging, or maybe using a file name as a key? I guess if your db is just key-value with string keys maybe (basically a file system).

DJBunnies 6y ago

Uuid v5 is namespaced.

skissane 6y ago
But given a v3 or v5 UUID, you can’t tell what namespace it belongs to. Both are one way functions from (namespace,name) -> uuid. The gp is asking for a way to tell user uuid apart from group uuid just by looking at the uuid. That is actually possible with the v2 uuids used with DCE. But, since just about nobody uses DCE any more, just about nobody uses v2 uuids either
- pbronez 6y ago
  What is DCE?
  - skissane 6y ago
    https://en.m.wikipedia.org/wiki/Distributed_Computing_Environment https://en.m.wikipedia.org/wiki/Distributed_Computing_Enviro...

globular-toast 6y ago

Why would you ever be in a situation where you have a UUID but don't know what it refers to?

seppel 6y ago
* You stumble upon them in log files or error messages. * Somebody asks you why some API call is not working. * You send around Excel files to higher management (for example in incidents).
- globular-toast 6y ago
  Now I'm even more baffled. What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies? Why would you need to communicate uuids to higher management? This makes me think of Douglas Adams. You know the answer is 42 but you forgot what the question was. I really can't imagine how this could ever happen in a business. "Yes, sir, there was a problem with 1087." "1087 what?" "I don't know, but it was number 1087."
  - kube-system 6y ago
    I can think of a lot of reasons why it might happen. Maybe you have a process accepts multiple types of objects. Maybe you think you are passing in the correct type of object but you are not. Maybe the person reporting the error to you omitted information. Maybe the person who wrote the application didn't log enough context. Yes, all of these situations are not ideal, but if the process was ideal you wouldn't be debugging it in the first place. > I really can't imagine how this could ever happen in a business. "Yes, sir, there was a problem with 1087." "1087 what?" "I don't know, but it was number 1087." This happens all the time in many businesses. Users rarely generate perfect error reports, and it's not uncommon for intermediaries to incorrectly communicate details either. What developer hasn't seen an error report that consists of a vague screenshot with "doesn't work, got this error" as the description?
    - globular-toast 6y ago
      > Users rarely generate perfect error reports, and it's not uncommon for intermediaries to incorrectly communicate details either. What developer hasn't seen an error report that consists of a screenshot with "doesn't work, got this error" as the description? And the solution is to have them repeat a UUID to you? I don't think so...

SigmundA 6y ago

looks like its almost twice the size of a UUID at 30 bytes in this case with a short prefix, I'm assuming your storing this as a ascii string? That's a lot of extra bytes from some convenience when viewing logs or raw data etc. UUID's stored properly in binary form are only 16 bytes which can still be a concern over an 8 or 4 byte integer when you have a lot of them all over the place in a large db. (larger index more memory use).

StreamBright 6y ago
You can store UUIDs as bytes if you wish but when you are looking at it in a human readable form it will be still a UUID. I think storing UUID as text in 2021 is not that hard. >> UUID's stored properly in binary form are only 16 bytes Depending on what is your use case.
- SigmundA 6y ago
  >> You can store UUIDs as bytes if you wish but when you are looking at it in a human readable form it will be still a UUID. I think storing UUID as text in 2021 is not that hard. Not going to store a text type prefix + UUID in a 16byte UUID column, you will need a variable length text column. All your DB tools will convert UUID to human readable plus the column name no need to store in the data reading for every value. if your looking at network traffic or debugging the id will hopefully be keyed (json, query string, protobuf, etc) if your looking at plain text logs with no schema, sure emit the type-UUID for readability, in your logging code... >>Depending on what is your use case. Only use case I can think of is unstructured logging, or maybe using a file name as a key? I guess if your db is just key-value with string keys maybe (basically a file system).