⚡ Sangsakala Proxy 🏠 Home
Skip to content

Support nested set and list as types #5947

Closed

Description

@nquinn408

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

Activity

  1. soooojinlee commented on Feb 23, 2026

    @soooojinlee
    Contributor

    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.

  2. soooojinlee commented on Mar 13, 2026

    @soooojinlee
    Contributor

    hi, I'm currently working on this and had some questions out of curiosity

    1. 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.
    2. depth limit: the examples in issue are 2-level depth limit for now. Is that sufficient, or do you foresee needing deeper nesting?
  3. nquinn408 commented on Mar 19, 2026

    @nquinn408
    ContributorAuthor

    hi, I'm currently working on this and had some questions out of curiosity

    1. 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.
    2. depth limit: the examples in issue are 2-level depth limit for now. Is that sufficient, or do you foresee needing deeper nesting?

    @soooojinlee , thanks for asking.

    1. 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.
    2. I don't think we should limit at this point since the list and set I proposed above are without bound.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions