Is your feature request related to a problem? Please describe.
Prior to issue#4044 and the related PRs #4191, #4228, #4247, and #4258 for elasticity, fate transaction ids were longs. Now, fate transaction ids are objects (FateId) consisting of the long and the FateInstanceType. Now that the long id is centralized, it would be nice to change this from a 64 bit long to a 128 bit UUID. Further, FateIds should be sortable by UUID. The UUID should include the creation time, and first be sorted by the creation time. For example FateId1 < FateId2 means FateId1 was created before FateId2. This can be achieved with UUIDv7.
The benefits of this are:
- Collisions will be much less likely
- FateIds will be sortable by timestamp allowing for easier determination of the order in which Fate operations are created
Additional context
Further UUIDv7 context: #4044 (comment)
Is your feature request related to a problem? Please describe.
Prior to issue#4044 and the related PRs #4191, #4228, #4247, and #4258 for elasticity, fate transaction ids were longs. Now, fate transaction ids are objects (FateId) consisting of the long and the FateInstanceType. Now that the long id is centralized, it would be nice to change this from a 64 bit long to a 128 bit UUID. Further, FateIds should be sortable by UUID. The UUID should include the creation time, and first be sorted by the creation time. For example FateId1 < FateId2 means FateId1 was created before FateId2. This can be achieved with UUIDv7.
The benefits of this are:
Additional context
Further UUIDv7 context: #4044 (comment)