René's URL Explorer Experiment

Title: feat: Feast First-Class LabelView Implementation by ntkathole · Pull Request #6292 · feast-dev/feast · GitHub

Open Graph Title: feat: Feast First-Class LabelView Implementation by ntkathole · Pull Request #6292 · feast-dev/feast

X Title: feat: Feast First-Class LabelView Implementation by ntkathole · Pull Request #6292 · feast-dev/feast

Description: What this PR does / why we need it: RFC - https://docs.google.com/document/d/1mcJM0sHeBk269oMIsLsLnAlrMtgnxn5Pws0oEeogc48/edit?usp=sharing Summary Introduces LabelView, a new alpha-stage Feast primitive that manages mutable labels and annotations separately from immutable feature data stored in regular FeatureViews. This supports multi-labeler workflows (human reviewers, automated safety scanners, reward models) where different sources independently write labels for the same entity keys. LabelView is fully opt-in — existing workflows are unaffected unless a user explicitly defines one. labelview_v2.mov What's included Core implementation (feast.labeling module) LabelView class inheriting from BaseFeatureView, with label-specific attributes: labeler_field, conflict_policy, retain_history, reference_feature_view ConflictPolicy enum (LAST_WRITE_WINS, LABELER_PRIORITY, MAJORITY_VOTE) Protobuf definition (LabelView.proto) with LabelViewSpec, LabelViewMeta, and ConflictResolutionPolicy Full SDK integration FeatureStore.apply() — registers LabelViews, auto-registers their PushSource, validates name uniqueness across all view types FeatureStore.push() — routes push data to LabelView when its PushSource matches FeatureStore.get_historical_features() — works via batch_source/stream_source properties on LabelView FeatureStore.teardown() — includes LabelView tables FeatureStore.list_label_views() / get_label_view() — new public API methods FeatureService composability — LabelViews can be included alongside regular feature views Registry support (all backends) File registry — full CRUD, apply_materialization, name-conflict checks SQL registry — label_views table, _infer_fv_table/_infer_fv_classes support, proto() builder Remote (gRPC) registry — label_view arm added to ApplyFeatureViewRequest oneof, full client + server wiring Snowflake registry — DDL for LABEL_VIEWS table, correct column-name mapping in delete_feature_view CLI feast label-views list — lists all label views with name, entities, conflict policy feast label-views describe — shows full label view details feast feature-views list unchanged (label views are only in their dedicated command) Permissions LABEL_VIEW = 11 added to Permission.proto Type enum _PERMISSION_TYPES map updated for from_proto/to_proto roundtrip Regression safety No changes to existing feature-views list output All registry proto() builders include label_views so cached/exported blobs are complete Cross-type name uniqueness enforced via _ensure_feature_view_name_is_unique Documentation Docstrings with [Alpha] tags and Google-style Args blocks on all public classes/methods Sphinx/RST API reference entries for LabelView and ConflictPolicy Concept guide (docs/getting-started/concepts/label-view.md) with usage examples, conflict policies, and alpha limitations Alpha limitations clearly documented: conflict_policy stored but not enforced at read time (requires online-store query-path changes); retain_history stored but not enforced at write time (requires online-store write-path changes); batch materialization not supported Tests 30 unit tests covering creation, defaults, proto roundtrip, copy/equality, validation, FeatureService composition, registry proto roundtrip, batch_source/stream_source properties, name-conflict detection, and MaterializationTask acceptance Alpha Limitations conflict_policy — persisted in registry metadata but not enforced during get_online_features. Online store returns last-written row regardless of policy. retain_history — persisted but not acted on. Online store always overwrites previous value. Test Plan All 30 test_label_view.py unit tests pass All 5 test_registry_diff.py tests pass (including test_diff_registry_objects_permissions) No linter errors introduced Existing feature view / entity / feature service workflows unaffected when no LabelView is defined Manual: feast apply with a repo containing a LabelView definition Manual: feast label-views list / feast label-views describe Manual: FeatureStore.push() to a LabelView's PushSource Which issue(s) this PR fixes: #5456

Open Graph Description: What this PR does / why we need it: RFC - https://docs.google.com/document/d/1mcJM0sHeBk269oMIsLsLnAlrMtgnxn5Pws0oEeogc48/edit?usp=sharing Summary Introduces LabelView, a new alpha-stage Feast prim...

X Description: What this PR does / why we need it: RFC - https://docs.google.com/document/d/1mcJM0sHeBk269oMIsLsLnAlrMtgnxn5Pws0oEeogc48/edit?usp=sharing Summary Introduces LabelView, a new alpha-stage Feast prim...

Opengraph URL: https://github.com/feast-dev/feast/pull/6292

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width