Support nil or empty uuid

[ali92hm]

Is your feature request related to a problem? Please describe.

I wanted to go ahead and make a PR for adding nil uuid which is a special case. Before doing the work, I just wanted to double check to see if this has been considered before or there are any objections to it.

You can read more about nil uuid https://en.wikipedia.org/wiki/Universally_unique_identifier#Nil_UUID

Describe the solution you'd like

I was thinking about adding nill to the namespace so the user can write the following code:

import { nil } from 'uuid';
console.log(nil()); // => '00000000-0000-0000-0000-000000000000'

I believe that is valid for all versions, so we dont need to implement it under v1, v2, etc.
Let me know your thoughts and I'll get to it.

[ctavan]

@ali92hm sorry for the slow response time. Could you elaborate a bit more on the use cases of nil UUIDs? I'm totally aware that they exist, but I'm not really aware of any use cases.

We are currently extending the API of this library a bit anyways (adding validation and parsing), so adding nil UUIDs for the sake of completeness might be an option. I'd still understand the benefits of having that a bit better though.

[broofa]

See also #236

1. The validate() and version() methods added in this (v9) branch already work with nil uuids. No change needed there.
2. Use of the nil UUID is an antipattern, and we should not be promoting it's use by exposing it in this API. (No citation for this as I just made this up. See below.)

My rational for that latter argument is simple: Anywhere you would need to use the nil UUID, there are better, more generalized nil/null/NULL/None constructs that will work more seamlessly with existing toolchains. For example, testing for undefined values - if (!id) in JS, if id is None in python, etc - or UNIQUE SQL DB columns that should allow multiple NULL values.

[Yes, this qualifies as "opinionated software", and there's an argument to be made that it's not our place as module maintainers to make these sorts of judgements. But... worth considering?]

[ali92hm]

I'd leave it up to you, but @broofa I agree with the generalized nil/null/NULL/None being better than using the nil UUID.

Our use case was having a PG db column where the type is set to UUID and have it non-nullable (because we have very small percentage of the values occasionally being nil) which doesn't make sense to make the full column nullable and potentially deal with missing data.

Here is the use case:

row.column = value || uuid.nill()

We then later found a pg extension that does that automatically. I'm still not fully sold on this being a better solution than using a nullable column (because of the reasons you mentioned). Just thought having it here for the sake of completeness may not be bad.

[broofa]

have it non-nullable

What's the benefit here? Does this help DB performance?

[Edit: Asking for my own edification. As noted above, as a module maintainer it's probably better to avoid these sorts of debates.]

[broofa]

I guess I'd be okay adding this. At the end of the day, we're talking about one line of code for the NIL or NIL_UUID constant (which can be removed with tree-shaking). Maybe document it with a note about preferring the use of native constructs for null values, though.

[ali92hm]

Haha, I understand the curiosity part and as I mentioned I'm on the fence about which solution is better. I.e. have the column to be nullable and have null values for missing one or have the column to be non-nullable and have nil uuid for the missing ones.

In most of our tables we have the column marked as nullable, but for this table the null values are truly the edge case and not the norm (the value for the column should be present at all times). I'm not sure about db performance, but in my experience making something nullable will accumulate more null values than it is necessary and will lead to null checks all over the code.

In this specific case we don't care what the value of the UUID is as long as there is a string value. It's mostly for BI purposes.

[IsaiahJTurner]

I don't have any opinions on this feature but just saw the issue and wanted to share a nil uuid use case from: https://developer.apple.com/documentation/adsupport/asidentifiermanager/1614151-advertisingidentifier

The advertisingIdentifier is an alphanumeric string unique to each device, that you only use for advertising. Specific uses are for frequency capping, attribution, conversion events, estimating the number of unique users, advertising fraud detection, and debugging.
The advertising identifier has a value of 00000000-0000-0000-0000-000000000000 until authorization is granted or when using the Simulator.

So, there are a lot of client's which do conditional logic on the backend to handle it. Why Apple does this perplexes me but they do.

[ctavan]

@ali92hm @IsaiahJTurner we have just released uuid@8.3.0-beta.0 which includes https://github.com/uuidjs/uuid#uuidnil would you mind testing it and report if that works for you?

[ali92hm]

Yes, I was able to make the following work

console.log(uuid.NIL)

[ctavan]

We have just released uuid@8.3.0 which should fix this issue. Please report back if there any problems.

[ali92hm]

Sill works, thank you!

[iuriguilherme]

Not really a widely used case, but I want to share why I use the NIL UUID and why I always define it in my code.

It is to use it as a name space when creating reproducible uuid3s and uuid5s from strings. One could argue that I don't need the uuid5 because I can straight up use the string itself, but for consistence reasons I need to store my variables in a "UUID only" storage.