What @aaronsheldon says is completely correct and delightfully well-documented with references.
In application development, we often need (or desire) to create some unique-ish identifier. But as Aaron points out, a six-digit number will not suffice.
If you want to generate an asymptotically-increasing serial number, you can in fact do this with Bubble, but you need to follow a very specific workflow, as outlined in this classic thread – if you’d like to just skip to the solution, read this specific summary reply.
But of course, in between, I have a great video explicating the problem and solution.
(Also, at this point, I like to point out that all Things in your Bubble database already have a Unique ID and so I feel this sort of thrashing is stupid and pointless, but some people just don’t like the appearance of that Unique ID. Whaddyagonnado?)
NOW, we of course do not have to limit ourselves to numbers for our unique ID string. For example, Bubble’s unique ID for Things is a set of numeric characters joined with “x” by another string of numeric characters. And, hence it is a string (what Bubble calls a text), and not a numeric value.
By increasing the number of symbols in the alphabet that we use to construct our unique ID, we can reduce the number of symbols we need to create more-or-less-universally-unique random strings without risk of collision.
Because this is such a common thing, my List Shifter plugin actually includes an implementation of the NanoID library (this shouldn’t be a surprise because, of course, my plugins are full of awesome surprises), which is great (and more efficient than UUID) at generating universally-unique values.
If you’d like to experiment with the collision risk inherent in different unique ID schemes, the NanoID folks have a really great one here:
https://zelark.github.io/nano-id-cc/
Using this tool, you can see how collision-prone a six-digit, randomly generated numeric string is:
what this tells us is that, if we generate just 6-digit numeric strings at a (very slow) rate of ONLY 10 per second it will take us only 14 seconds to be at a risk of a 1% chance of a collision!
If we were to change our alphabet to the set of all URL-safe characters (that is, we go from 10 symbols to 64 symbols), the same computation would still only take about 1 hour before there is a 1% chance of a collision:
Now, of course, we can see that this is still hardly “unique” in computing terms.
But what if we go to the default length that Nano ID uses (21 characters) with the full URL-safe alphabet? Here’s what we find:
In this case, it will take FOUR BILLION YEARS (approximately the age of the planet we live on) before there is a 1% risk of a collision (again generating 10 of these values per second).
If we look at even higher rates, we still find very good (unique for all intents and purposes) perfomance:
if we compute 100,000 of these things per hour, it will still take us ONE BILLION YEARS to reach a 1% chance of collision!
That will probably do, eh?
With List Shifter, you can use the “PROCESS List” action to generate Nano ID-computed “unique IDs” with a length of your choosing (I don’t let you pick the alphabet, which always uses the default).
Here’s a little example: When you click the “Generate IDs” button on this page, it generates ONE MILLION NanoIDs and then tells you if there are any duplicates (if there are no duplicates, the Number of Unique values will be 1000000. (And, BTW: If you do find duplicates at a length of 21 symbols, you should run right out and buy yourself a Powerball ticker, as it’s your fucking lucky day.)
Here’s the example page:
Runtime: https://list-shifter-demo.bubbleapps.io/version-test/list-shifter-nanoid?debug_mode=true