-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Historical retrieval without an entity dataframe (Local Only) #1690
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: charliec443 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @charliec443. 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. Instructions 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. |
raise FeatureViewNotFoundException(entity_df) | ||
|
||
entity_df_event_timestamp_col = DEFAULT_ENTITY_DF_EVENT_TIMESTAMP_COL # local modifiable copy of global variable | ||
if entity_df_event_timestamp_col not in entity_df.columns: |
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.
The only time we "visit" this code is if the entity_df
provided is a pd.DataFrame
- should we exclude this from happening? Or should the method be renamed.
5c8f2db
to
0b53477
Compare
sdk/python/feast/feature_store.py
Outdated
end_date, | ||
) | ||
except FeastProviderLoginError as e: | ||
sys.exit(e) |
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 think we should avoid using sys.exit(e)
in general. The current implementation of get_historical_features()
is wrong and will be changed. The exit command will also exit the wrapping process.
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'm guessing this is related to #1666
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files@@ Coverage Diff @@
## master #1690 +/- ##
===========================================
- Coverage 84.46% 69.69% -14.78%
===========================================
Files 82 80 -2
Lines 7093 7087 -6
===========================================
- Hits 5991 4939 -1052
- Misses 1102 2148 +1046
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
780a602
to
7688a71
Compare
06415f9
to
0c99eeb
Compare
48e02ff
to
8dfbce9
Compare
Thanks @charliec443, this is great. We might only get to a review a bit later this week, but intending to have a closer look. |
f"Please provide an entity_df of type {type(pd.DataFrame)} or {type(str)} instead of type {type(entity_df)}" | ||
) | ||
|
||
if isinstance(entity_df, str): |
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.
Are you assuming that a str
is a reference to a feature view? What if the user provides a SQL query?
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.
Is a SQL query relevant for file-based offline stores?
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.
Is a SQL query relevant for file-based offline stores?
It isn't, but what happens when we generalize this code to other feature stores? Are you suggesting we'd have different APIs for different offline stores?
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.
It could be a query. For the other offline stores the parameter could be "entity_df_or_query"? I'm rather indifferent towards this.
Happy to go with any approach you think is sensible.
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 think what is confusing to me is why get_historical_features_by_view
even supports Pandas/Query if it's by view. What if we just supported a string reference (or even an object reference) to a feature view, and nothing else?
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.
Yes, let's do that. It removes the ambiguity.
8562ee2
to
6eee18f
Compare
3243480
to
abe5aba
Compare
rebase is driving me nuts |
abe5aba
to
c7c8bff
Compare
Sorry about that. We are busy with a lot of refactoring right now. Feel free to blow away your history and just provide one commit. |
Signed-off-by: CS <2498638+charliec443@users.noreply.github.com>
5e8053e
to
d10c66a
Compare
Hi @charliec443 , are you still planning on working on this PR? Is there anything we can do to help? |
What this PR does / why we need it:
Adds Historical retrieval without an entity dataframe as per #1611
This is experimental
Implements #1611 for Local Provider only.
Which issue(s) this PR fixes:
Partially adds #1611
Does this PR introduce a user-facing change?: