GeezerVison is showing github.com — Add uuid as feature types · Issue #5885 · feast-dev/feast
Add uuid as feature types #5885DescriptionIs 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 to uuid1(). Activitychanged the title [-]Add new uuid types[/-] [+]Add uuid as feature types[/+] on Jan 21, 2026soooojinlee commented on Jan 24, 2026 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 transformations
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?
If everything above aligns with what you expect, could you also assign this issue to me?
Thanks! franciscojavierarceo commented on Jan 24, 2026 UUIDs are strings and time stamps are supported types. Are those primitives insufficient?
Can you give a sample transformation that outlines the gap? nquinn408 commented on Jan 24, 2026 ContributorAuthor More actions @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. nquinn408 commented on Jan 24, 2026 ContributorAuthor More actions
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! nquinn408 commented on Jan 31, 2026 ContributorAuthor More actions @soooojinlee , I am unable to assign this issue to you, but feel free to pick it up in a separate issue. Thanks! franciscojavierarceo commented on Jan 31, 2026
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|