[HN Gopher] GUIDs Are Not the Only Answer
       ___________________________________________________________________
        
       GUIDs Are Not the Only Answer
        
       Author : ublaze
       Score  : 12 points
       Date   : 2021-01-05 20:56 UTC (2 hours ago)
        
 (HTM) web link (www.softwareatscale.dev)
 (TXT) w3m dump (www.softwareatscale.dev)
        
       | gnulinux wrote:
       | Why not just `f"task-{uuid.uuid4()}"`?
        
       | withinboredom wrote:
       | GUID v6 is pretty nice when you need monotonously increasing
       | numbers that are globally unique.
       | 
       | On another note, I worked somewhere that prefixed GUIDs with the
       | environment the app was running on. All of production, staging,
       | even dev machines all used the same connection string.
       | 
       | There was even a stored procedure to copy user accounts, etc of
       | prod for your machine. It was hands-down the best debugging
       | experience when a customer had an issue.
        
       | BillinghamJ wrote:
       | I would strongly say strings are actually the _only_ type you
       | should use for IDs. Prevents the vast majority of buggy client
       | behaviour and gives you good flexibility to change how you do
       | things over time.
       | 
       | ---
       | 
       | My company ended up with a simple KSUID implementation of our own
       | - https://www.cuvva.com/product-updates/showing-off-our-fancy-...
       | (having originally used UUIDs and Mongo ObjectIDs)
       | 
       | For us, a big part of it was usability with cursor selection etc
       | - in addition to it being immediately obvious what the ID was
       | for.
       | 
       | Once we finally had that rolled out everywhere, we ended up
       | collecting up every other ID we'd ever used and mapped it to its
       | KSUID resource equivalent, so now all our IDs work standalone
       | without type/context info, even across environments (and
       | thankfully we'd never had any collisions on the old IDs)
       | 
       | ---
       | 
       | Going back to the typing - the most difficult part of migrating
       | our IDs actually was converting them all to string types. With
       | Postgres this is a little slow but ultimately fine, but with
       | Mongo you have to actually remove and reinsert every document -
       | you cannot (or at least could not) update IDs in place.
        
       | nesarkvechnep wrote:
       | "At the very least, identifiers should not be allowed to float
       | freely as strings or integers in order to prevent a class of
       | inconsistency bugs."
       | 
       | Tell that to almost every Typescript developer who uses `number`
       | for identifiers.
        
         | crooked-v wrote:
         | Typescript doesn't have functionality for non-equivalent types
         | with identical primitives or interfaces (e.g. you can't have
         | string-equivalent type A [?] string-equivalent type B), though
         | there's ongoing discussion around adding it
         | (https://github.com/Microsoft/TypeScript/issues/202).
        
         | 0xdeafcafe wrote:
         | Arctic take.
        
       | ff333ttee wrote:
       | I also tried to use custom types for IDs, but in my opinion, it
       | has more cons than pros. I have to write custom serializers and
       | model binders for them, explicitly convert them to other types,
       | write separate validators etc... At the end I finished with even
       | more bugs than before.
        
       | yrimaxi wrote:
       | Pretty obvious stuff. Of course GUIDs are more unweildy to read
       | etc. compared to simple auto-incrementing integers.
       | 
       | I don't see a reason to prefix an id with something like `task-`.
       | I would rather leave it to the display logic.
        
       ___________________________________________________________________
       (page generated 2021-01-05 23:01 UTC)