4 ms·

* 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 manageme

by 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...
    - kube-system 6y ago
      Something can be not a solution to a problem, but contribute to making your life easier. This is that. There are certainly applications that have type-ambiguous IDs which work just fine too. Not all engineers make the same decisions; that's ok.
- rkalla 6y ago
  You seem... fun.
- seppel 6y ago
  > What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies? The code cannot know what kind of object an uuid identifies, it can only assume that it identifies what it expects. So it you might see: "Unknown person 550e8400-e29b-11d4-a716-446655440000" in the log files. Much more helpful for debugging, however, is: "Unknown person order-550e8400-e29b-11d4-a716-446655440000". Then you know somebody accidentally put an order id where a person id belongs. This is an easy example, in the real world you have persons, groups, representatives, accounts, acls, etc, which are easily confused. If you just have an uuid, you will have a hard time figured out what it actually is.
  - SigmundA 6y ago
    This is why you have column headers? If you just want it to look that way in a text log, then sure prepend the type with the id wasting some space there, but to use it throughout your db eats up tons of space from both text encoding the id and repeating the column name in the data over and over.
    - StreamBright 6y ago
      >> but to use it throughout your db eats up tons of space I think human resources and outages cost a lot more than disk space these days. If I can trade disk space for either of those I will do it in a blink of an eye.
      - SigmundA 6y ago
        Not just disk space, larger index size mean less fits in caches and memory, more I/O etc. These are keys which are typically used constantly by an app in the db with joins etc. They are some of the hottest data typically and you want to avoid cache misses on them if possible.
    - seppel 6y ago
      > This is why you have column headers? I'm not sure I can follow. You get an uuid from somewhere, probably external code that you cannot even look at. The uuid comes stringly-typed, let's say as json. Then you have no chance to know what type it is, you can only assume it is the correct type that you expect. Just putting "550e8400-e29b-11d4-a716-446655440000" into a person colum does not make it a person id. If you get instead "order-550e8400-e29b-11d4-a716-446655440000" as a typed-uuid, you know for sure that this is not a person id. It is an order id. Somebody made a mistake somewhere. You also know that you probably have to look in the order DB to debug what it actually refers to. > but to use it throughout your db eats up tons of space from both text encoding the id You dont need to put your uuid in this format into the db. You can add/remove the type before/after accessing the db.
- Hnsuz 6y ago
  Exactly.
- jamescampbell 6y ago
  I am with you. This makes no sense to me. But I also have wrapped userdata or account data in a generated hash to quickly have access to the underlying account info / expiration info etc. I think it is easier to justify why to implement vs. why not to implement.

by 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...
  - kube-system 6y ago
    Something can be not a solution to a problem, but contribute to making your life easier. This is that. There are certainly applications that have type-ambiguous IDs which work just fine too. Not all engineers make the same decisions; that's ok.
rkalla 6y ago
You seem... fun.
seppel 6y ago
> What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies? The code cannot know what kind of object an uuid identifies, it can only assume that it identifies what it expects. So it you might see: "Unknown person 550e8400-e29b-11d4-a716-446655440000" in the log files. Much more helpful for debugging, however, is: "Unknown person order-550e8400-e29b-11d4-a716-446655440000". Then you know somebody accidentally put an order id where a person id belongs. This is an easy example, in the real world you have persons, groups, representatives, accounts, acls, etc, which are easily confused. If you just have an uuid, you will have a hard time figured out what it actually is.
- SigmundA 6y ago
  This is why you have column headers? If you just want it to look that way in a text log, then sure prepend the type with the id wasting some space there, but to use it throughout your db eats up tons of space from both text encoding the id and repeating the column name in the data over and over.
  - StreamBright 6y ago
    >> but to use it throughout your db eats up tons of space I think human resources and outages cost a lot more than disk space these days. If I can trade disk space for either of those I will do it in a blink of an eye.
    - SigmundA 6y ago
      Not just disk space, larger index size mean less fits in caches and memory, more I/O etc. These are keys which are typically used constantly by an app in the db with joins etc. They are some of the hottest data typically and you want to avoid cache misses on them if possible.
  - seppel 6y ago
    > This is why you have column headers? I'm not sure I can follow. You get an uuid from somewhere, probably external code that you cannot even look at. The uuid comes stringly-typed, let's say as json. Then you have no chance to know what type it is, you can only assume it is the correct type that you expect. Just putting "550e8400-e29b-11d4-a716-446655440000" into a person colum does not make it a person id. If you get instead "order-550e8400-e29b-11d4-a716-446655440000" as a typed-uuid, you know for sure that this is not a person id. It is an order id. Somebody made a mistake somewhere. You also know that you probably have to look in the order DB to debug what it actually refers to. > but to use it throughout your db eats up tons of space from both text encoding the id You dont need to put your uuid in this format into the db. You can add/remove the type before/after accessing the db.
Hnsuz 6y ago
Exactly.
jamescampbell 6y ago
I am with you. This makes no sense to me. But I also have wrapped userdata or account data in a generated hash to quickly have access to the underlying account info / expiration info etc. I think it is easier to justify why to implement vs. why not to implement.