Added .with_name method in FeatureView/OnDemandFeatureView classes for name aliasing. FeatureViewProjection will hold this information - #1872
Conversation
|
Hi @mavysavydav. Thanks for your PR. I'm waiting for a feast-dev member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Codecov Report
@@ Coverage Diff @@
## master #1872 +/- ##
==========================================
- Coverage 82.34% 82.22% -0.13%
==========================================
Files 96 96
Lines 7490 7512 +22
==========================================
+ Hits 6168 6177 +9
- Misses 1322 1335 +13
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
|
Btw @mavysavydav your thoughts on #1868 (comment) would be appreciated since it may slightly change this PR. |
|
We may want to add another case to the feast/sdk/python/feast/errors.py Lines 144 to 157 in e98d65a |
|
Cool, added the FeatureNameCollisionError msg modification |
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
|
/retest |
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: achals, mavysavydav The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| string feature_view_name = 1; | ||
|
|
||
| // Alias for feature view name | ||
| string feature_view_name_to_use = 3; |
There was a problem hiding this comment.
I dont think this is an appropriate name. "Name to use" is confusing if you dont understand the context. What if it's unset, would we use a blank string?
What about feature_view_name_alias?
There was a problem hiding this comment.
name_alias seemed like an obvious choice, but it didn't seem to fit for the following reason. My thinking was that name_to_use defaults to the name and it always has a value. Either the alias or the original name. So when projection.name_to_use is used, the name that will be used is returned, whereas with projection.name_alias, one might think -- does it have an alias set? If not, should I do a check? To me, name_to_use is less conventional than a term like an alias, but it seems clear in meaning "the name that will be used". I can see how ppl may find it unfamiliar though and maybe hesitate to assume that it means exactly as it's worded especially if they don't know the use case. Happy to change it.
There was a problem hiding this comment.
So when projection.name_to_use is used, the name that will be used is returned, whereas with projection.name_alias, one might think -- does it have an alias set? If not, should I do a check?
I think this is where I see it differently. The caller shouldn't have to check which one is set. They should just ask for name. We should be able to place the conditional logic within a Python property, right?
Of course, we do need a different name in that case though. We can't just have name refer to both the original and the name that has been aliased.
So perhaps
field: name
field: name_alias
method: get_name()
or
method: name_to_use()
In the latter case I am slightly more comfortable with name_to_use since at a storage level we are still keeping the fields separate and clear. My beef with name_to_use is really that it's not a descriptive name. It doesnt convey its meaning. Shouldnt all the code we write be usable? Ideally we'd have something more specific imho, but I dont have any good ideas except above.
There was a problem hiding this comment.
ok works for me. I'll make the change
| @dataclass | ||
| class FeatureViewProjection: | ||
| name: str | ||
| name_to_use: str |
There was a problem hiding this comment.
What about just alias or name_alias?
|
|
||
| def with_name(self, name: str): | ||
| """ | ||
| Produces a copy of this OnDemandFeatureView with the passed name. |
There was a problem hiding this comment.
What isn't clear is why?
What about
Renames this feature view by setting an alias for the feature view name. This rename operation is only used as part of query operations and will not modify the underlying feature view.?
…r name aliasing. FeatureViewProjection will hold this information (feast-dev#1872) * Added .with_name method in FV with test case Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Correctly sort imports Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * correct lint errors Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Modified FeatureNameCollisionError msg Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * fixed error msg test Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * updated code to preserve original FV name in base_name field Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Updated proto conversion methods and fixed failures Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * fixed proto numberings Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * wip Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Cleaned code up Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * added copy method in FVProjections Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * use python's copy lib rather than creating new copy method. Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
…r name aliasing. FeatureViewProjection will hold this information (feast-dev#1872) * Added .with_name method in FV with test case Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Correctly sort imports Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * correct lint errors Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Modified FeatureNameCollisionError msg Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * fixed error msg test Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * updated code to preserve original FV name in base_name field Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Updated proto conversion methods and fixed failures Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * fixed proto numberings Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * wip Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * Cleaned code up Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * added copy method in FVProjections Signed-off-by: David Y Liu <davidyliuliu@gmail.com> * use python's copy lib rather than creating new copy method. Signed-off-by: David Y Liu <davidyliuliu@gmail.com>
Signed-off-by: David Y Liu davidyliuliu@gmail.com
What this PR does / why we need it:
#1867
Which issue(s) this PR fixes:
Fixes #1867
Does this PR introduce a user-facing change?: