Starting with 4D 20 R10, UUIDs are now generated directly using an internal algorithm instead of relying on system functions—giving you better control over their format and behavior. And with this update, you can now opt for version 7 UUIDs, which support chronological sorting. Let’s explore what this means for your applications.

Understanding UUID Versions

All UUIDs share the same format: 128 bits represented by 32 hexadecimal characters (0-9 + A-F). However, they can encode different types of information. The RFC 9562 currently defines eight UUID versions. Internally, a UUID is stored in two 64-bit integers, making comparison, querying and sorting extremely efficient on 64-bit CPUs. Hexadecimal characters are just for display format and are used internally.
Until now, 4D relied on system functions to generate UUIDs. These functions didn’t allow you to choose or even know which version was used. In practice, they typically produced version 4 UUIDs—completely random.
With the RFC’s recent evolution, version 7 was introduced. It embeds a timestamp, making UUIDs sortable by creation time. Many of you requested support for UUIDv7 in the 4D Feature Request forum, and we’re happy to deliver it in 4D 20 R10!

Version 4 Still by Default

To ensure consistency and compatibility, 4D continues to use version 4 UUIDs by default. However, 4D no longer relies on system functions to generate UUIDs, but now computes them internally. This helps prevent any unexpected changes due to future system updates.
And if you want to take advantage of version 7’s chronological sorting, you can now enable it—either through settings or code.

What Makes Version 7 Special?

Version 7 UUIDs begin with a Unix Epoch timestamp, allowing them to be sorted chronologically. This is especially useful during development or debugging, when you want newly created records to appear at the top (or bottom) of a list box.
Since version 7 uses microsecond precision, it offers finer granularity than the traditional Timestamp command, which is limited to milliseconds.
Note: If multiple records are created within the same microsecond, they’ll share the same timestamp portion. However, their UUIDs will still be unique thanks to additional random bytes. Sorting those specific records may not be meaningful, but sorting them alongside others remains useful. In practice, record creation usually takes longer than a microsecond, so this edge case is rare.

New Setting for Version 7 Auto UUIDs

Activating version 7 for auto-generated UUIDs is simple. Just open the Structure Settings dialog, go to the Database > Data Storage page, and select the desired UUID version.

Once set to version 7, all auto-generated UUIDs—such as those used for primary keys—will follow the new format.
Existing UUIDs in your database remain untouched to preserve consistency. And since the difference between version 4 and 7 is internal (not structural), both formats can coexist without issue.

Generate Version 7 UUIDs in Code

The Generate UUID command has also been updated to support version 7. You just have to specify the version as a parameter!

It’s that simple!
And if the parameter is missing, the version used by default is still 4, to keep your code consistent.

var $uuid : Text
$uuid:=Generate UUID // v4: 578BFEC987BD4C11AE8AB9CD3DC12DD0
$uuid:=Generate UUID(4) // v4: C2BE4B6723634DBE9F4387B1226A4B4F
 
$uuid:=Generate UUID(7) // v7: 0198C7A4E41A7B6CB39F460873165D30
$uuid:=Generate UUID(7) // v7: 0198C7A543557F89AA7D83563AB5C97E

Here’s a quick comparison of the results above:

• Version 4 UUIDs are fully random.
• Version 7 UUIDs share a common prefix (timestamp), with randomness at the end.

We hope this new feature gives you more flexibility and control over your developments. As always, we’re listening to your feedback and evolving 4D to meet your needs.
Happy coding!