RFC 9562 defines UUID v7, as a timestamp based universally unique identifier (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). Supporting this type of UUID as the IdKey of persistent classes may have multiple advantages:
The ID is also a timestamp, so records are timestamp ordered by the creation time.
Subscript level mapping of a table's corresponding data global can follow calendar units (year, month).
The 16 byte long UUID v7 is still an integer formally in ObjectScript, bit functions can be used, so such an ID could still be used with bitmap indices.
!!!: as IDs can be generated independently from each other, the known limitations of $increment() and $sequence() would not apply to UUID v7 IDs in an ECP environment.
Thank you for submitting the idea. Based on information from our experts the status of your idea was changed to "Will not implement". Please look for details in the comments on the idea. Good luck!
While this may be an interesting UUID generator function, we think it's a better fit for a natural key (and foreign key target) than an IDKEY. We recommend against using any custom IDKEYs as they may preclude use of current and future optimizations. In particular, using this structure would lead to highly fragmented bitmap indices and columnar structures, likely cancelling out any ingest-time gains with query-time pains.
If the goal is to map data to different databases, please see the Table Partitioning capability currently available through EAP and slated for release with 2026.1