Is RANDOMSTRING() something that I never have to worry about there being a collision? What is the algorithm it uses? Is it really random, or is it more like a sequence generator that won’t repeat? Do the 17 bytes include some kind of hashed timestamp so that they can’t repeat?
I’m kind of wishing for an actual GUID generator.
Hey @wz2b
The random string function can conceivably return a duplicate value. This can be check for with triggers. The generated random string can be stored to to a variable, then you can check to see if a record exists with that ID, if it does, generate a new random ID.
Having said that, a 17 character case sensitive alpha-numeric has a potential 2.95 X 10^30 unique options. This is ~30 order of magnitude more than the count of atoms in the known universe. Unfortunately generating truly random strings isn’t possible. I reached out to our developers to understand what we are using for the seed value for the random string generator. I will update this thread when I have an answer.
As a little more context - There is a feature in the works right now where records could be created with a random id without the need of an expression, the RANDOM_STRING() function, etc. This will respect GUID principals and insure no duplicates are generated. The RANDOM_STRING() function has a place, but shouldn’t be needed to do something as universal as creating records.
Pete
As promised, here is the update with more technical details -
Random strings are being generated using Meteor’s random number generator which on the browser is implemented using the Web Crypto API. There’s no explicit seeding, it has about 96 bits of entropy (versus 128 for traditional GUID), and the RNG is cryptographically secure, so a repetition is very unlikely.
Some users will add the current time (in epoch) to the random string to eliminate the chance of a repeat, let me know if you need more detail on how to implement this.
Pete
Thanks, that’s good for now! I don’t mind adding something to the string, that seems reasonable, but based on your description I’m not even sure it’s necessary. Long term I think Tulip could consider other ways to handle this, for the use case of generating history/event logs that need truly unique IDs. I agree the probability of a collision is very very low. But, if it DID happen it would be pretty confusing.
