1. 1

    A few thoughts

    • if your language allows you to cast ints to other types that are not numeric in the traditional sense (php), you are opening yourself up to a huge class of bugs regardless of if uids are ints or not
    • when combining large amounts of data, some jurisdictions imply that incremented uids are also PII (IANAL). although i suppose if you’re at the stage where you need to choose between bigint and uuid, you don’t have to be concerned with that just yet!
    • UUIDs help prevent against IDORs (but don’t rely on it!)
    • UUIDs shouldn’t be a problem for database keys, if you’re at the scale where you’re having issues, you’d probably need to shard your database (mod n) anyways. Also, every modern database supports robust and fast UUID based indexing.
    • If you’re building a community site, low user IDs are considered a badge of pride (or can cause problems!), so there’s a social aspect as well to this choice
    1. 2

      if your language allows you to cast ints to other types that are not numeric in the traditional sense (php),

      I think the problem is less “can you type cast?” and more “can you accidentally type case?” https://3v4l.org/bmLu5

    1. 5

      As always, resist the temptation to over-generalize. If your test case has conditions for specific parameters, you may be falling into this trap.

      Also, every framework has a different way for doing parameterized tests, but I prefer parameterized on python3.

      1. 1

        Migrating a bunch of old apps off of a deprecated VM platform. Boring busywork, but I’d say that having machines stay running for 6 years without issue (and auto-updates) is a pretty good tradeoff.

        At work, continuing my work to opensource a tool we use internally that I built (modern, typed Py3!).