Repository navigation
Add uuid as feature types #5885
Description
Activity
Hi! I'm interested in taking on this issue and wanted to confirm the expected scope.
My understanding of the minimum requirements for UUID support is:
Allow declaring UUID as a dtype for Features/Entities
When retrieving online features, return uuid.UUID objects instead of plain strings
Ensure UUID values are preserved correctly in on-demand transformationsThe issue also mentions supporting uuid1 / uuid4.
Could you clarify whether these should be separate types, or if handling the version within a single UUID type is sufficient?If everything above aligns with what you expect, could you also assign this issue to me?
Thanks!
UUIDs are strings and time stamps are supported types. Are those primitives insufficient?
Can you give a sample transformation that outlines the gap?
@franciscojavierarceo I agree. The reason to add is two fold. First, the burden should not be on user to convert. It could affect latency and betrays point of disambiguating definition from serving. Second, the underlying storage may utilize it. For example, Cassandra is able to range queries over time uuids.
Hi! I'm interested in taking on this issue and wanted to confirm the expected
Wonderful!
The issue also mentions supporting uuid1 / uuid4. Could you clarify whether these should be separate types, or if handling the version within a single UUID type is sufficient?
I just want the conversion to be clear for user both in definition and when reading. If python reads back as uuid only, then it is ambiguous.
If everything above aligns with what you expect, could you also assign this issue to me?
Sure!
@soooojinlee , I am unable to assign this issue to you, but feel free to pick it up in a separate issue. Thanks!
Reacted by Soojin LeeAssigned!
Reacted by Soojin Lee- added 4 commits that reference this issue
on Feb 8, 2026 - added 4 commits that reference this issue
on Feb 11, 2026 - added a commit that references this issue
on Feb 16, 2026 - added a commit that references this issue
on Feb 19, 2026 - added a commit that references this issue
on Mar 27, 2026 - added 2 commits that reference this issue
on Apr 7, 2026
Is your feature request related to a problem? Please describe.
Support random uuid and time uuid features is missing.
Describe the solution you'd like
We should add support for random and time based uuids as feast feature types.
Describe alternatives you've considered
We can store uuids as strings but then burden of converting back to uuid is on calling client. Also, we won't be able to add logic to transformation which uses uuid and time based uuid.
Additional context
Random uuid will be mapped to
uuid4()in python and time based uuid will be mapped touuid1().