Entity value_type inference for Feature Repo registration

[mavysavydav]

Signed-off-by: David Y Liu [email protected]

What this PR does / why we need it:
This change enables users to register Entities without needing to specify the value_type because we'll be able to infer it based on finding the entity column in the table based on the Entity name and using that type. Milestone 2 of this RFC.

Which issue(s) this PR fixes:

Fixes #1500

Does this PR introduce a user-facing change?:

This change enables users to register Entities without needing to specify the value_type because we'll be able to infer it based on finding the entity column in the table based on the Entity name and using that type.  More details can be found in this doc as milestone 2 -- https://docs.google.com/document/d/1MkWvexE4e5nYWcQLELFnJ5o9OlJDKC2rn_USHMDT9dg/edit#heading=h.pqhio4s5uw2s. 

[feast-ci-bot]

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[jklegar]

/ok-to-test

[jklegar]

/kind feature

[jklegar]

Thanks @mavysavydav this looks great! The one thing I see is that there's also a way to apply a specific set of entities/feature views on the FeatureStore class here:

feast/sdk/python/feast/feature_store.py

Line 179 in 8712826

def apply(

Note it's an "incremental apply" rather than a "total apply" so only the new/to-be-updated entities/feature views are passed in.
Would you be able to add entity inference in there as well?

[mavysavydav]

Sounds good, will take a look

[codecov-commenter]

Codecov Report

Merging #1538 (6dc6104) into master (dfb029d) will increase coverage by 0.06%.
The diff coverage is 95.83%.

@@            Coverage Diff             @@
##           master    #1538      +/-   ##
==========================================
+ Coverage   83.59%   83.65%   +0.06%     
==========================================
  Files          65       67       +2     
  Lines        5753     5812      +59     
==========================================
+ Hits         4809     4862      +53     
- Misses        944      950       +6     

Flag	Coverage Δ
integrationtests	83.56% <95.83%> (+0.06%)	⬆️
unittests	77.85% <87.50%> (+0.49%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
sdk/python/feast/entity.py	96.36% <ø> (ø)
sdk/python/tests/utils/data_source_utils.py	100.00% <ø> (ø)
sdk/python/feast/repo_operations.py	32.17% <50.00%> (+0.17%)	⬆️
sdk/python/feast/feature_store.py	91.85% <88.88%> (-0.04%)	⬇️
sdk/python/feast/inference.py	95.45% <95.45%> (ø)
sdk/python/tests/conftest.py	100.00% <100.00%> (ø)
sdk/python/tests/test_feature_store.py	100.00% <100.00%> (ø)
sdk/python/tests/test_inference.py	100.00% <100.00%> (ø)
sdk/python/feast/telemetry.py	61.53% <0.00%> (-1.09%)	⬇️
sdk/python/feast/data_source.py	78.77% <0.00%> (-0.07%)	⬇️
... and 13 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dfb029d...6dc6104. Read the comment docs.

[mavysavydav]

Ready for another round of review. Sorry for the mess in this PR. Accidentally messed up my branch when syncing w master

[woop]

Ready for another round of review. Sorry for the mess in this PR. Accidentally messed up my branch when syncing w master

Thanks @mavysavydav

[mavysavydav]

btw I made the assumption that for featurestore.apply, we'd only want to infer the entities based on the feature_views passed in as part of that apply call. The reason I thought this was reasonable is that the alternative suggests a feature_view has been applied with an entity that hasn't been defined yet. Though in the case of redefinitions of entities, inferring from previously applied FeatureViews seems like ok behavior but that won't be done with the current logic. Happy to reconsider if ppl disagree.

[woop]

/lgtm

[feast-ci-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mavysavydav, woop

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [woop]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment