There isn't a uuid() function for JSONata

[dubnemo]

#390 discusses the challenge, but the core issue was solved therefore that could be closed an a new issue to focus on that be created.

The use case: while iterating in a map, a new uuid needs to be generated and assigned to a property for each array entry.

[ipauler]

Maybe it's not what you're looking for, but you can register your own function for your expression.
We're using that a lot for our use case, we have a library of functions we're using, all of them are pre-registered before running evaluation.
https://docs.jsonata.org/embedding-extending#expressionregisterfunctionname-implementation-signature

[dubnemo]

@ipauler the intent of this ticket is to build this function in the core of JSONata. Most transformation languages I have worked with have similar functions built-in.
E.g., DataWeave does this now:
https://docs.mulesoft.com/dataweave/latest/dw-core-functions-uuid
That is only one of many. The recommended goal is to make JSONata more 'enterprise-grade'.

[gary-menzel]

I happen to agree with @ipauler - While $uuid() could be useful, when I look through most of the built-in functionality of jsonata it seems like it mostly just mimics what is available in JavaScript (which makes sense given it is a tool to manipulation JSON with various expressions).

I am using custom functions for various things and don't find it too much of a hassle to just create my own $uuid() function. That way, I get to pick the algorithm and library used - another goal of jsonata is to stay dependency free. As soon as one dependency is added (and possibly not the flavour of UUID you want) it opens the flood-gates for all sorts of dependencies ot be added. The custom function approach is there to alleviate that.

Given the importance that a UUID function suits the use-case and that it needs to be reliably robust, I'd prefer it not be added to jsonata built-in functions.

[andrew-coleman]

Timely comment because I was in the process of preparing a PR for adding this function, specifically the version 4 (random) UUID as specified in https://datatracker.ietf.org/doc/html/rfc9562#name-uuid-version-4

It uses the built-in crypto API included with node and most browsers (https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID) so it doesn't add any third party dependencies.

As with any built-in function, it can be overridden with your own implementation using the mechanism describe above.

[dubnemo]

@andrew-coleman I think a basic IETF v4 approach is best, and let others override with their favorite flavors. This gap came up in call with NIST Systems Integration Division and they were baffled as well why UUID wasn't core. This is the right approach.

[mattbaileyuk]

#731 is the current proposed approach, but we've ran into the problem of webcrpyto not being considered stable, and therefore available as a global, until Node.js 19. So to adopt this we'd need to drop support below Node.js 20, which is not something we'd want to do while Node.js 18 is still a support LTS release. However, this changes end of April, so we might wait until then, do a major version bump and bring this in.

[gary-menzel]

I am only just becoming active with jsonata but I am happy with the proposed change. I use uuid V4 anyway - so I could remove my custom function. And I am using Node.js 18 - so would appreciate it if it were compatible with that.