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
Agreed, I'd add that although class BatchFeatureView exists in the codebase, it's basically unused at this point and not part of registry CRUD operations. Even if it was, once #4235 gets resolved, do you think it's still a good idea not to treat FeatureViews as a single object type?
Even if it was, once #4235 gets resolved, do you think it's still a good idea not to treat FeatureViews as a single object type?
I'm not against having a single type but I cannot estimate the impacts on the registry (endpoints and diff logic).
In the permission model we're using a filter to allow selecting only specific types and exclude sub-classes, which again should be reviewed.
Pls note that OnDemandFeatureView is a BaseFeatureView only, this would either need its entry in FeastObject or to review its hierarchy.
Activity
dmartinol commentedon Jun 24, 2024
@tokoko
tokoko commentedon Jun 24, 2024
Agreed, I'd add that although class
BatchFeatureViewexists in the codebase, it's basically unused at this point and not part of registry CRUD operations. Even if it was, once #4235 gets resolved, do you think it's still a good idea not to treat FeatureViews as a single object type?dmartinol commentedon Jun 25, 2024
Can I take this one and send a PR?
tokoko commentedon Jun 25, 2024
sure, go ahead
dmartinol commentedon Jun 25, 2024
I'm not against having a single type but I cannot estimate the impacts on the registry (endpoints and diff logic).
In the permission model we're using a filter to allow selecting only specific types and exclude sub-classes, which again should be reviewed.
Pls note that
OnDemandFeatureViewis aBaseFeatureViewonly, this would either need its entry inFeastObjector to review its hierarchy.