3 ms·

On one hand I agree. On the other; Legal Names change: for lots of reasons. It makes a LOT of sense to store a UID the way *NIX systems often do. An explicit

On one hand I agree. On the other; Legal Names change: for lots of reasons. It makes a LOT of sense to store a UID the way *NIX systems often do. An explicit indirect lookup table entry.

shagie 4y ago
The question is "are you passing that ID around as an int? or as a byte array?" It may happen that the data type in the database is an int... because the database does math on it (or its source - seq.nextval type thing). However, when you get it, you don't need to have it be an int that you can do math with. Even if you keep the same underlying implementation of it, pass it around in a way that doesn't let you add two IDs together or mutate it. The easiest way to do that is to store it as a String. One of the advantages of taking it to a String in Java is that it becomes immutable and so can cleanly be used as a key to a Map and prevents the easy math operations on it without taking it from a String to a numeric type (and back). If you see someone doing `Integer.parseInt(someId)` it becomes clear that they're doing something wrong with that.
- mjevans 4y ago
  The file format / interface API shouldn't make assumptions about the use case. A Display Name (what humans interface with) and the 'internal identity in the system' (be that a UUID, a bare number, an exact string, whatever) should BOTH be available. As an example, a backup / archive of a project is created. Years later it is restored, but now several employees have new names. Maybe some automation accounts got renamed too. Should the restoration fail when no user ID is present? Or should it instead restore the internal / native IDs? What if a user by the same name does exist, but they got re-added or the users migrated to a different authentication method and now have different internal / native IDs? So you store the lookup table. Maybe even use a third tiny integer column if there aren't that many users. Store the platform ID and also the name. Though also have an option to not store or flatten that information.

On one hand I agree. On the other; Legal Names change: for lots of reasons. It makes a LOT of sense to store a UID the way *NIX systems often do. An explicit indirect lookup table entry.

shagie 4y ago

The question is "are you passing that ID around as an int? or as a byte array?" It may happen that the data type in the database is an int... because the database does math on it (or its source - seq.nextval type thing). However, when you get it, you don't need to have it be an int that you can do math with. Even if you keep the same underlying implementation of it, pass it around in a way that doesn't let you add two IDs together or mutate it. The easiest way to do that is to store it as a String. One of the advantages of taking it to a String in Java is that it becomes immutable and so can cleanly be used as a key to a Map and prevents the easy math operations on it without taking it from a String to a numeric type (and back). If you see someone doing `Integer.parseInt(someId)` it becomes clear that they're doing something wrong with that.

mjevans 4y ago
The file format / interface API shouldn't make assumptions about the use case. A Display Name (what humans interface with) and the 'internal identity in the system' (be that a UUID, a bare number, an exact string, whatever) should BOTH be available. As an example, a backup / archive of a project is created. Years later it is restored, but now several employees have new names. Maybe some automation accounts got renamed too. Should the restoration fail when no user ID is present? Or should it instead restore the internal / native IDs? What if a user by the same name does exist, but they got re-added or the users migrated to a different authentication method and now have different internal / native IDs? So you store the lookup table. Maybe even use a third tiny integer column if there aren't that many users. Store the platform ID and also the name. Though also have an option to not store or flatten that information.