Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide FeatureViewProjections from user interface & have FeatureViews carry FVProjections that carries the modified info of the FeatureView #1899
Hide FeatureViewProjections from user interface & have FeatureViews carry FVProjections that carries the modified info of the FeatureView #1899
Changes from 13 commits
0e802f4
f17b075
e24d04a
ffe284a
37b6d87
2971740
86b3665
afc07d5
dfdf35e
9e00be5
35411b3
e69ad89
bf8eb94
009edf4
d65326d
659374a
31cd6a8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so is there a convention here like
feature_table:feature
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, would it make more sense to use a feature reference instead of a string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep that's the convention. I'll add a note on that expectation in the docstring. It should be a string instead of feature reference since we need to know which feature view the feature name is associated with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A feature reference contains a reference to its associated view/table https://github.com/feast-dev/feast/blob/master/protos/feast/serving/ServingService.proto#L52. I actually think the FeatureViewProjection object has a good structure for this use case, even if we remove it from the rest of the user facing API. Wouldn't it be safer and more convenient to split views/tables from feature names vs having to rely on string conventions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what these new objects are supposed to contain. Don't we just need
features
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FeatureViews and OnDemandFeatureViews will carry the info of the modified fields such as modified name. I also added a field for FeatureTable for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this now, it doesn't look like the right approach. Wouldn't we run into consistency problems if we store copies of feature view objects with different configurations?
The original problem was
This is both a user facing API problem and a code duplication problem, but I am beginning to think that having an object like a FeatureViewProjection within the protos might be the right approach. Assuming the user could modify a FeatureView at their own whims, and assuming we could convert that final feature view into something like
Wouldn't that both solve the consistency problem in the registry (normalized instead of denormalized), as well as the user facing API problem where we have to maintain FeatureViewProjections?
This file was deleted.