You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Support Set<Set> or List> as well as Set<List> and List>. Makes sense to support more verbose version of set and list of edge cases.
Describe the solution you'd like
Support set and list
Describe alternatives you've considered
None available as part of definition and proto file
Hi, I'd like to take this on. I'm currently working on UUID/TIME_UUID type support (https://github.com/feastdev/feast/pull/5885) which involved extending types.py, type_map.py, and Value.proto, so I have good context on the type system pipeline.
hi, I'm currently working on this and had some questions out of curiosity
use case: Could you share the specific scenario that motivated this request? Knowing what kind of data you're storing as nested collections would help ensure the implementation fits your needs.
depth limit: the examples in issue are 2-level depth limit for now. Is that sufficient, or do you foresee needing deeper nesting?
hi, I'm currently working on this and had some questions out of curiosity
use case: Could you share the specific scenario that motivated this request? Knowing what kind of data you're storing as nested collections would help ensure the implementation fits your needs.
depth limit: the examples in issue are 2-level depth limit for now. Is that sufficient, or do you foresee needing deeper nesting?
I am a platform developer so I am not aware of all of the data science reasons. At the same time, we have MAP (which is a map<string, Value>) and I thought it would be nice to have symmetry and offer LIST (repeated Value) and SET (set<Value>). I know we have xxxLIST and xxxSET for all primitive types so this would just be a catch-all for other List and Set features.
I don't think we should limit at this point since the list and set I proposed above are without bound.
Activity
soooojinlee commentedon Feb 23, 2026
Hi, I'd like to take this on. I'm currently working on UUID/TIME_UUID type support (https://github.com/feastdev/feast/pull/5885) which involved extending types.py, type_map.py, and Value.proto, so I have good context on the type system pipeline.
soooojinlee commentedon Mar 13, 2026
hi, I'm currently working on this and had some questions out of curiosity
feat: Support nested collection types (Array/Set of Array/Set) (feast…
feat: Support nested collection types (Array/Set of Array/Set) (feast…
nquinn408 commentedon Mar 19, 2026
@soooojinlee , thanks for asking.
map<string, Value>) and I thought it would be nice to have symmetry and offer LIST (repeated Value) and SET (set<Value>). I know we have xxxLIST and xxxSET for all primitive types so this would just be a catch-all for other List and Set features.feat: Support nested collection types (Array/Set of Array/Set) (feast…
feat: Support nested collection types (Array/Set of Array/Set) (feast…
feat: Support nested collection types (Array/Set of Array/Set) (feast…
feat: Support nested collection types (Array/Set of Array/Set) (#5947) (
chore(release): release 0.61.0
chore(release): release 0.62.0