-
-
Save mikelehen/3596a30bd69384624c11 to your computer and use it in GitHub Desktop.
/** | |
* Fancy ID generator that creates 20-character string identifiers with the following properties: | |
* | |
* 1. They're based on timestamp so that they sort *after* any existing ids. | |
* 2. They contain 72-bits of random data after the timestamp so that IDs won't collide with other clients' IDs. | |
* 3. They sort *lexicographically* (so the timestamp is converted to characters that will sort properly). | |
* 4. They're monotonically increasing. Even if you generate more than one in the same timestamp, the | |
* latter ones will sort after the former ones. We do this by using the previous random bits | |
* but "incrementing" them by 1 (only in the case of a timestamp collision). | |
*/ | |
generatePushID = (function() { | |
// Modeled after base64 web-safe chars, but ordered by ASCII. | |
var PUSH_CHARS = '-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz'; | |
// Timestamp of last push, used to prevent local collisions if you push twice in one ms. | |
var lastPushTime = 0; | |
// We generate 72-bits of randomness which get turned into 12 characters and appended to the | |
// timestamp to prevent collisions with other clients. We store the last characters we | |
// generated because in the event of a collision, we'll use those same characters except | |
// "incremented" by one. | |
var lastRandChars = []; | |
return function() { | |
var now = new Date().getTime(); | |
var duplicateTime = (now === lastPushTime); | |
lastPushTime = now; | |
var timeStampChars = new Array(8); | |
for (var i = 7; i >= 0; i--) { | |
timeStampChars[i] = PUSH_CHARS.charAt(now % 64); | |
// NOTE: Can't use << here because javascript will convert to int and lose the upper bits. | |
now = Math.floor(now / 64); | |
} | |
if (now !== 0) throw new Error('We should have converted the entire timestamp.'); | |
var id = timeStampChars.join(''); | |
if (!duplicateTime) { | |
for (i = 0; i < 12; i++) { | |
lastRandChars[i] = Math.floor(Math.random() * 64); | |
} | |
} else { | |
// If the timestamp hasn't changed since last push, use the same random number, except incremented by 1. | |
for (i = 11; i >= 0 && lastRandChars[i] === 63; i--) { | |
lastRandChars[i] = 0; | |
} | |
lastRandChars[i]++; | |
} | |
for (i = 0; i < 12; i++) { | |
id += PUSH_CHARS.charAt(lastRandChars[i]); | |
} | |
if(id.length != 20) throw new Error('Length should be 20.'); | |
return id; | |
}; | |
})(); |
Im so grateful finding this ❤️ thank you
port in elixir https://hex.pm/packages/firebase_pushid
Did pushid changed in firebase lately? None of the thousands of ids generated contains dash (-) or underscore (_). Or anything apart from alphanumeric characters.
Swift 4: https://gist.github.com/AhmedOS/512531b74da37f34331ecb206c77c20a
Modified version of pgherveou's one.
Made a JSFiddle: https://jsfiddle.net/feLys02r/1/
It's the original script with a button to copy to clipboard.
Port in Unity C#: https://gist.github.com/bhupiister/05dbb860e9064c43e8176b591f11e555
Just paste this script into unity and assign text field and function on a button.
Thank you to the original content maker
here is the codesandox for this code!
https://codesandbox.io/s/firebase-push-id-generator-080cb
Thanks @mikelehen & @Flyclops , for sharing the code.
My usecase is that we are transforming a firebase application (which uses firebase auth) and generates an uuid based on the above algorithm, however, we needed to convert it to a W3C DID, here is a simple code
var gb64 = "-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"
func genB32(m string) (string, error) {
encb64 := base64.NewEncoding(gb64)
dec, err := encb64.DecodeString(m)
if err != nil {
return "", err
}
return base32.StdEncoding.WithPadding(base32.NoPadding).EncodeToString(dec), nil
}
see line Line 77 of https://play.golang.org/p/vnCZTqOjZp9
Thank you for sharing <3
Best way:
`
function generatePushID() {
// Modeled after base64 web-safe chars, but ordered by ASCII.
var PUSH_CHARS = '-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz';
// Timestamp of last push, used to prevent local collisions if you push twice in one ms.
var lastPushTime = 0;
// We generate 72-bits of randomness which get turned into 12 characters and appended to the
// timestamp to prevent collisions with other clients. We store the last characters we
// generated because in the event of a collision, we'll use those same characters except
// "incremented" by one.
var lastRandChars = [];
var now = new Date().getTime();
var duplicateTime = (now === lastPushTime);
lastPushTime = now;
var timeStampChars = new Array(8);
for (var i = 7; i >= 0; i--) {
timeStampChars[i] = PUSH_CHARS.charAt(now % 64);
// NOTE: Can't use << here because javascript will convert to int and lose the upper bits.
now = Math.floor(now / 64);
}
if (now !== 0) throw new Error('We should have converted the entire timestamp.');
var id = timeStampChars.join('');
if (!duplicateTime) {
for (i = 0; i < 12; i++) {
lastRandChars[i] = Math.floor(Math.random() * 64);
}
} else {
// If the timestamp hasn't changed since last push, use the same random number, except incremented by 1.
for (i = 11; i >= 0 && lastRandChars[i] === 63; i--) {
lastRandChars[i] = 0;
}
lastRandChars[i]++;
}
for (i = 0; i < 12; i++) {
id += PUSH_CHARS.charAt(lastRandChars[i]);
}
if(id.length != 20) throw new Error('Length should be 20.');
return id;
}
console.log(generatePushID());
`
Hi All,
Is there a possibility to have a pure numeric version?
Hello, here you can find a porting for PostgreSQL:
https://github.com/marcopeg/amazing-postgresql/tree/main/projects/firebase-pushid
Oh nice! Thanks for noting this here @marcopeg. :)
The beginning of the push ID is based on the current timestamp. This is what makes push IDs sort chronologically. Around the year 2110 the first character will change from a -
to a 0
.
The beginning of the push ID is based on the current timestamp. This is what makes push IDs sort chronologically. Around the year 2110 the first character will change from a
-
to a0
.
thanks that makes sense, now do we know why isn't Firebase applying the same methodology?
just to weigh the pros and cons as it seems a bit weird Google would not apply the most rational approach no?
See https://stackoverflow.com/a/52741265 and https://firebase.google.com/docs/firestore/best-practices. In particular:
Do not use monotonically increasing document IDs ... Such sequential IDs can lead to hotspots that impact latency.
Basically monotonically increasing IDs can have performance implications so Firestore opted to avoid this by default. If you need chronological ordering you need to add a separate timestamp field to your documents and sort by that.
ok thanks!
@iboxgithub This ID is for real time database, NOT firestore.
@iboxgithub This ID is for real time database, NOT firestore.
ha...is there a reason why? we use it in Firestore already :(
This key was designed before Google bought Firebase. It allows automatic sorting by time using only the key in a gigantic json file, which real time database kinda is. This was a design choice of Firebase engineers. At that time Firestore did not exist.
After Google bought Firebase, it became evident that Real Time database is too limited. Firestore was designed to be an evolution of Google's Datastore, which is completely different beast. To guarantee the (almost) endless scaling of the database, it needs evenly distributed keys, which this is not. Firestore needs truly random keys to work properly. This, to my knowledge, is because they use multiple machines behind the scenes and divide the data to different machines by the key. Now, if the key is aaaa1, aaaa2, aaaa3... all of the docs end up in single machine creating a hot spot that hit's the limits quite fast.
If you don't have much data, you won't notice it. (The data is in single machine anyway.)
thanks ;)
@SVincent, you have your calculations wrong I think: