DEV Community

Cover image for THE most absurd way of creating unique identifiers.
Torsten Dittmann
Torsten Dittmann

Posted on

THE most absurd way of creating unique identifiers.

Today I ran into an issue. The guy sitting next to me in the university was trying out PouchDB and was confused by the identifiers. It was illogical for him why he had to determine the ID for each document himself.
In my last project I just generated a random number and asked if it already existed. Actually quite bad, but it worked.

Then I asked my friend Google and came across a solution on Stackoverflow.

At that moment I was shocked how simple this approach was and how I never came up with this idea.

Just create an ID using the current UNIX Timestamp with new Date().getTime()

But after a short thought I asked myself a question. Does this approach still work when my code generates many records in a row?

For the demonstration I use PouchDB.

With PouchDB you can create a batch of documents with db.bulkDocs()

db.bulkDocs([
{
    title : 'Record 1', 
    _id: +new Date()
},
{
    title : 'Record 2', 
    _id: +new Date()
}
]).then(function (result) {
    console.log(result);
}).catch(function (err) {
    console.log(err);
});
Enter fullscreen mode Exit fullscreen mode

As you might expect, only the first entry will be created and the second one will return an error because it is done in the same timestamp and end up with the same _id.

I needed something more accurate than milliseconds. I was helped by performance.now().

Unlike other timing data available to JavaScript (for example Date.now), the timestamps returned by performance.now() are not limited to one-millisecond resolution. Instead, they represent times as floating-point numbers with up to microsecond precision.

Also unlike Date.now(), the values returned by performance.now() always increase at a constant rate, independent of the system clock (which might be adjusted manually or skewed by software like NTP).

So if I combine these two methods, I should end up with a very accurate Unique Identifier.

Lets create this simple function:

function uniqueID() {
    return new Date().getTime().toString().concat(performance.now());
}
Enter fullscreen mode Exit fullscreen mode

And output some data:

console.log(new Date().getTime());
// Output: 1568115683706

console.log(performance.now());
// Output: 218.28000000095926

console.log(uniqueID());
// Output: 1568115683706218.28000000095926
Enter fullscreen mode Exit fullscreen mode

Even if this seems completely absurd in my eyes, I can hardly think of a possibility that he runs on an error because of an already existing ID.

Because in every millisecond of the current UNIX timestamp the value of five thousandths of a millisecond (5 microseconds) of the runtime is added.

Let's use above uniqueID() function like this:

db.bulkDocs([
{
    title : 'Record 1', 
    _id: uniqueID() // 1568116510818456.76499999899534
},
{
    title : 'Record 2', 
    _id: uniqueID() // 1568116510819456.94000000003143
}
]).then(function (result) {
    console.log(result);
}).catch(function (err) {
    console.log(err);
});
Enter fullscreen mode Exit fullscreen mode

As you can see, between the two entries, the difference from the results is large enough.

Of course, this approach can lead to a problem if millions of users work with the same database. But on a small scale it shouldn't run into a problem.

I am always open for ideas or suggestions. What do you think about this approach?

GitHub logo TorstenDittmann / absurdUID

Javascript function that generates a unique string based on the UNIX timestamp and the runtime.

absurdUID.js

Javascript function that generates a unique string based on the UNIX timestamp and the runtime.

Why?

Today I ran into an issue. The guy sitting next to me in the university was trying out PouchDB and was confused by the identifiers. It was illogical for him why he had to determine the ID for each document himself In my last project I just generated a random number and asked if it already existed. Actually quite bad, but it worked.

Then I asked my friend Google and came across a solution on Stackoverflow.

At that moment I was shocked how simple this approach was and how I never came up with this idea.

Just create an ID using the current UNIX Timestamp with new Date().getTime()

But after a short thought I asked myself a question. Does this approach still work when my code generates many records in a row?

For…

Top comments (3)

Collapse
 
tiagosmx profile image
Tiago Stapenhorst Martins

Hey Torsten, awesome approach! I like your simple solution despite most developers tend to generate unique ids through UUIDv4. You see, there is a "secret" benefit in using timestamp based instead of random generated ids (such as UUIDv4). When you persist them in a table/database with btree index over the id column you will be helping the index because values will always be added in ascending order, in a controlled way, preventing index bloat (nearly empty / empty index pages).

You will likely have a faster insertion rate, smaller index size and perform less reindexing operations.

Collapse
 
juuyan profile image
Yan

Interesting. But I think you should still add a method to handle a potential error of conflict, shouldn't you?

Collapse
 
torstendittmann profile image
Torsten Dittmann

True, might do in the future. But this package was more like a fun project a long time ago.

So I wouldn't recommend ever using this in production :-D