feat: Add version tracking to FeatureView#6101
Conversation
…emandFeatureView Every `feast apply` now creates a version snapshot. Users can pin a feature view to a specific historical version declaratively via `version="v2"`. By default, the latest version is always served. - New proto: FeatureViewVersion.proto with version record/history - Added `version` field to FeatureViewSpec, StreamFeatureViewSpec, OnDemandFeatureViewSpec and version metadata to their Meta messages - New version_utils module for parsing/normalizing version strings - Version-aware apply_feature_view in both SQL and file registries - New `list_feature_view_versions` API on FeatureStore and registries - CLI: `feast feature-views versions <name>` subcommand - Updated all 14 templates with explicit `version="latest"` - Unit tests (28) and integration tests (7) for versioning Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
- Fix current_version_number=0 being silently dropped during proto deserialization in FeatureView, OnDemandFeatureView (proto3 int32 default 0 is falsy in Python); use spec.version to disambiguate - Add current_version_number restoration in StreamFeatureView.from_proto (was missing entirely) - Use timezone-aware UTC datetime in SqlRegistry.list_feature_view_versions for consistency with the rest of the codebase - Add test for v0 proto roundtrip Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
- Add Versioning section to feature-view.md concept page covering automatic snapshots, version pinning, version string formats, CLI usage, and Python SDK API - Add `feast feature-views versions` command to CLI reference Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
- Fix current_version_number roundtrip bug: version="latest" (always truthy) caused None to become 0 after proto roundtrip; now check that spec.version is not "latest" before treating 0 as intentional - Use write_engine (not read_engine) for pre/post apply reads in SqlRegistry to avoid read replica lag causing missed version snapshots - Remove redundant version check in StreamFeatureView.__eq__ (parent FeatureView.__eq__ already checks it) - Add else clause to StreamFeatureView.from_proto for consistency - Add test for latest/None roundtrip preservation Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
…ntly - delete_feature_view now also deletes version history records, preventing IntegrityError when re-creating a previously deleted FV - _get_next_version_number uses write_engine instead of read_engine to avoid stale version numbers with read replicas Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
- Add step-by-step walkthrough showing how versions auto-increment on changes and skip on identical re-applies - Add CLI example showing the apply/change/apply cycle - Clarify that pinning ignores constructor params and uses the snapshot - Explain how to return to auto-incrementing after a pin/revert Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 BatchFeatureView missing version parameter — incomplete transformation (sdk/python/feast/batch_feature_view.py:80-102)
FeatureView, StreamFeatureView, and OnDemandFeatureView all accept a version parameter in their constructors, but BatchFeatureView.__init__ (sdk/python/feast/batch_feature_view.py:80-102) does not. Furthermore, BatchFeatureView.__init__ does not pass version to super().__init__() at sdk/python/feast/batch_feature_view.py:144-158. This means users cannot construct a BatchFeatureView with a pinned version (e.g., BatchFeatureView(..., version="v2") raises TypeError), and any BatchFeatureView created directly always defaults to version="latest". The proto round-trip path works because FeatureView.from_proto sets feature_view.version after construction, but the constructor API is inconsistent with the other feature view types.
View 19 additional findings in Devin Review.
Raises FeatureViewPinConflict when a user pins to an older version while also modifying the feature view definition (schema, source, etc.). Fixes FeatureView.__copy__() to include description and owner fields, which was causing false positive conflict detection. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 BatchFeatureView missing version parameter — incomplete transformation (sdk/python/feast/batch_feature_view.py:80-102)
FeatureView, StreamFeatureView, and OnDemandFeatureView all accept a version parameter in their constructors, but BatchFeatureView.__init__ (sdk/python/feast/batch_feature_view.py:80-102) does not. Furthermore, BatchFeatureView.__init__ does not pass version to super().__init__() at sdk/python/feast/batch_feature_view.py:144-158. This means users cannot construct a BatchFeatureView with a pinned version (e.g., BatchFeatureView(..., version="v2") raises TypeError), and any BatchFeatureView created directly always defaults to version="latest". The proto round-trip path works because FeatureView.from_proto sets feature_view.version after construction, but the constructor API is inconsistent with the other feature view types.
View 23 additional findings in Devin Review.
- Add version parameter to BatchFeatureView constructor for consistency with FeatureView, StreamFeatureView, and OnDemandFeatureView - Clean up version history records in file registry delete_feature_view to prevent orphaned records on re-creation - Fix current_version_number proto roundtrip: preserve 0 when version="latest" (after first apply) instead of incorrectly returning None Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Clarify that versioning provides definition management and rollback, not concurrent multi-version serving. Document recommended approaches (separate projects or distinct FV names) for A/B testing scenarios. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Extends feature view versioning with support for reading features from specific
versions at query time using the syntax: "driver_stats@v2:trips_today"
Core changes:
- Add _parse_feature_ref() to parse version-qualified feature references
- Update all feature reference parsing to use _parse_feature_ref()
- Add get_feature_view_by_version() to BaseRegistry and all implementations
- Add FeatureViewProjection.version_tag for multi-version query support
- Add version-aware _table_id() in SQLite online store (v0→unversioned, v1+→_v{N})
- Add VersionedOnlineReadNotSupported error for unsupported stores
Features:
- "driver_stats:trips" = "driver_stats@latest:trips" (backward compatible)
- "driver_stats@v2:trips" reads from v2 snapshot using _v2 table suffix
- Multiple versions in same query: ["driver@v1:trips", "driver@v2:daily"]
- Version parameter added to all decorator functions for consistency
Backward compatibility:
- Unversioned table serves as v0, only v1+ get _v{N} suffix
- All existing queries work unchanged
- SQLite-only for now, other stores raise clear error
Documentation:
- Updated feature-view.md with @Version syntax examples
- Updated feature-retrieval.md reference format
- Added version examples to how-to guides
Tests: 47 unit + 11 integration tests pass, no regressions
Co-Authored-By: Claude Sonnet 4 <[email protected]>
- Fix type inference issues in get_feature_view_by_version() - Use distinct variable names for different proto types - Ensure proper type annotations for BaseFeatureView subclasses
|
I haven't been able to go through the whole thing yet, but iiuc the expectation is that online stores would be expected to handle this by essentially treating fv1@v1 and fv1@v2 as two different feature views, right? (sqlite example infers table name from the version). Just wondering, maybe that's to high a bat for online store implementations. for example, if you have fv1@v1 and fv1@v2 both containing 100 features that differ by a single feature only, the online store would have to keep redundant copies of the other 99 features or do some complicated logic to diff values and deduplicate. wdyt about concentrating on introducing versioning on feature level instead? tbh, that makes more intuitive sense to me. there's a feature called |
I spent some time reasoning about feature-level versioning with Claude. My initial reaction was that it's too large of a change and it only works today in a broken sense. By "in a broken sense" I mean that today we don't really version feature views or features, if someone changes the feature view or the feature, we just overwrite it and lose history. Moreover, we essentially force the materialization to be out of sync. Today, that just ignores the behavior silently. I like how we've implemented it here (i.e., creating a new table and storing the history of the metadata but allowing for callers to specify exact versions and defaulting to the existing behavior) because it is far more explicit about the challenges of materialization consistency issues when you change feature versions. So, I don't recommend we do feature-level versioning as I worry it makes materialization very unreliable. We can, in fact, declare feature view level versioning because transformations are a collection of features mapped one-to-one with a table. |
Implement optional feature view version metadata in API responses to address the issue where internal @v2 version syntax was leaking into client responses. Co-Authored-By: Claude Sonnet 4 <[email protected]>
Add missing include_feature_view_version_metadata parameter to: - EmbeddedGoOnlineFeaturesService.get_online_features() - FooProvider.get_online_features() and get_online_features_async() - FooProvider.retrieve_online_documents() and retrieve_online_documents_v2() This resolves CI failures where provider implementations were not updated with the new parameter from the abstract Provider interface. Co-Authored-By: Claude Sonnet 4 <[email protected]>
- Strip @latest suffix (equivalent to no version) instead of passing through as part of the FV name, which caused confusing "not found" errors - Pre-compile version tag regex to package-level var to avoid recompilation on every call in the hot path Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
* feat: Add version tracking to FeatureView, StreamFeatureView, and OnDemandFeatureView Every `feast apply` now creates a version snapshot. Users can pin a feature view to a specific historical version declaratively via `version="v2"`. By default, the latest version is always served. - New proto: FeatureViewVersion.proto with version record/history - Added `version` field to FeatureViewSpec, StreamFeatureViewSpec, OnDemandFeatureViewSpec and version metadata to their Meta messages - New version_utils module for parsing/normalizing version strings - Version-aware apply_feature_view in both SQL and file registries - New `list_feature_view_versions` API on FeatureStore and registries - CLI: `feast feature-views versions <name>` subcommand - Updated all 14 templates with explicit `version="latest"` - Unit tests (28) and integration tests (7) for versioning Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address PR review feedback from Devin - Fix current_version_number=0 being silently dropped during proto deserialization in FeatureView, OnDemandFeatureView (proto3 int32 default 0 is falsy in Python); use spec.version to disambiguate - Add current_version_number restoration in StreamFeatureView.from_proto (was missing entirely) - Use timezone-aware UTC datetime in SqlRegistry.list_feature_view_versions for consistency with the rest of the codebase - Add test for v0 proto roundtrip Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * docs: Add feature view versioning documentation - Add Versioning section to feature-view.md concept page covering automatic snapshots, version pinning, version string formats, CLI usage, and Python SDK API - Add `feast feature-views versions` command to CLI reference Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address second round of PR review feedback from Devin - Fix current_version_number roundtrip bug: version="latest" (always truthy) caused None to become 0 after proto roundtrip; now check that spec.version is not "latest" before treating 0 as intentional - Use write_engine (not read_engine) for pre/post apply reads in SqlRegistry to avoid read replica lag causing missed version snapshots - Remove redundant version check in StreamFeatureView.__eq__ (parent FeatureView.__eq__ already checks it) - Add else clause to StreamFeatureView.from_proto for consistency - Add test for latest/None roundtrip preservation Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Clean up version history on delete and use write_engine consistently - delete_feature_view now also deletes version history records, preventing IntegrityError when re-creating a previously deleted FV - _get_next_version_number uses write_engine instead of read_engine to avoid stale version numbers with read replicas Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * docs: Clarify versioning auto-increment behavior and pin/revert flow - Add step-by-step walkthrough showing how versions auto-increment on changes and skip on identical re-applies - Add CLI example showing the apply/change/apply cycle - Clarify that pinning ignores constructor params and uses the snapshot - Explain how to return to auto-incrementing after a pin/revert Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Add pin conflict detection to both file and SQL registries Raises FeatureViewPinConflict when a user pins to an older version while also modifying the feature view definition (schema, source, etc.). Fixes FeatureView.__copy__() to include description and owner fields, which was causing false positive conflict detection. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address Devin review feedback on versioning - Add version parameter to BatchFeatureView constructor for consistency with FeatureView, StreamFeatureView, and OnDemandFeatureView - Clean up version history records in file registry delete_feature_view to prevent orphaned records on re-creation - Fix current_version_number proto roundtrip: preserve 0 when version="latest" (after first apply) instead of incorrectly returning None Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * docs: Document concurrent multi-version serving limitations Clarify that versioning provides definition management and rollback, not concurrent multi-version serving. Document recommended approaches (separate projects or distinct FV names) for A/B testing scenarios. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat: Implement version-qualified feature references (@v<N>) Extends feature view versioning with support for reading features from specific versions at query time using the syntax: "driver_stats@v2:trips_today" Core changes: - Add _parse_feature_ref() to parse version-qualified feature references - Update all feature reference parsing to use _parse_feature_ref() - Add get_feature_view_by_version() to BaseRegistry and all implementations - Add FeatureViewProjection.version_tag for multi-version query support - Add version-aware _table_id() in SQLite online store (v0→unversioned, v1+→_v{N}) - Add VersionedOnlineReadNotSupported error for unsupported stores Features: - "driver_stats:trips" = "driver_stats@latest:trips" (backward compatible) - "driver_stats@v2:trips" reads from v2 snapshot using _v2 table suffix - Multiple versions in same query: ["driver@v1:trips", "driver@v2:daily"] - Version parameter added to all decorator functions for consistency Backward compatibility: - Unversioned table serves as v0, only v1+ get _v{N} suffix - All existing queries work unchanged - SQLite-only for now, other stores raise clear error Documentation: - Updated feature-view.md with @Version syntax examples - Updated feature-retrieval.md reference format - Added version examples to how-to guides Tests: 47 unit + 11 integration tests pass, no regressions Co-Authored-By: Claude Sonnet 4 <[email protected]> * fix: Resolve mypy type errors in proto_registry_utils.py - Fix type inference issues in get_feature_view_by_version() - Use distinct variable names for different proto types - Ensure proper type annotations for BaseFeatureView subclasses * feat: Add version metadata to clean @v2 syntax from feature names Implement optional feature view version metadata in API responses to address the issue where internal @v2 version syntax was leaking into client responses. Co-Authored-By: Claude Sonnet 4 <[email protected]> * fix: Update provider implementations with version metadata parameter Add missing include_feature_view_version_metadata parameter to: - EmbeddedGoOnlineFeaturesService.get_online_features() - FooProvider.get_online_features() and get_online_features_async() - FooProvider.retrieve_online_documents() and retrieve_online_documents_v2() This resolves CI failures where provider implementations were not updated with the new parameter from the abstract Provider interface. Co-Authored-By: Claude Sonnet 4 <[email protected]> * fix: Add version metadata parameter to all online store implementations Add missing include_feature_view_version_metadata parameter to: - SqliteOnlineStore.retrieve_online_documents/v2 - FaissOnlineStore.retrieve_online_documents - QdrantOnlineStore.retrieve_online_documents - MilvusOnlineStore.retrieve_online_documents_v2 - RemoteOnlineStore.retrieve_online_documents/v2 - PostgresOnlineStore.retrieve_online_documents/v2 - ElasticsearchOnlineStore.retrieve_online_documents/v2 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Resolve mypy type errors in versioning code - Fix _schema_or_udf_changed overrides to accept BaseFeatureView parameter type, satisfying Liskov substitution principle. Each subclass narrows via isinstance check in the method body. - Use getattr for __code__ access on UDF in StreamFeatureView to handle MethodType correctly. - Change _update_metadata_fields proto parameter from Message to Any since the method accesses .spec and .meta attributes. - Guard BaseFeatureView attribute access (online, offline, etc.) with hasattr checks in _update_metadata_fields. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address Devin review feedback on versioning - Fix version-qualified features dropped with full_feature_names=True: use _parse_feature_ref to build clean requested_result_row_names - Fix retrieve_online_documents breaking with @vn refs: use _parse_feature_ref instead of split(":") for FV name extraction - Fix metadata-only updates not committed: add self.commit() after _update_metadata_fields in file registry - Fix ODFV transforms broken by version-qualified refs: use _parse_feature_ref in _augment_response_with_on_demand_transforms - Fix _update_metadata_fields not updating spec.version: add version field update so pinned-to-latest transitions persist - Fix _resolve_feature_counts inflating FV count: strip @vn from feature view names in metrics - Fix version snapshots storing stale current_version_number: set version number before serializing snapshot in both file and SQL registries Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address additional Devin review feedback - Set spec.project on snapshot protos in SqlRegistry before serializing, so version snapshots include the correct project field - Fix _check_versioned_read_support to check projection.version_tag instead of current_version_number, so explicitly version-qualified reads (@v0) are correctly rejected on non-SQLite stores Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat: Make feature view versioning opt-in via registry config Versioning was always active on every `feast apply`. This adds an `enable_feature_view_versioning` boolean (default False) to RegistryConfig so version history, version pins, and version-qualified refs are only available when explicitly enabled. Existing behaviour is fully preserved when the flag is set to true. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address Devin review feedback on versioning issues - Fix SQLite _table_id to prefer projection.version_tag over current_version_number so @v2 refs read from the correct table - Detect feature name collisions for multi-version queries with full_feature_names=True (e.g. fv@v1:feat vs fv@v2:feat) - Remove unused include_feature_view_version_metadata parameter from retrieve_online_documents (v1) across all providers and online stores - Remove redundant name check from _schema_or_udf_changed since callers always match by name first Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Preserve version tag in response column names for multi-version queries When version-qualified refs (e.g. fv@v1:feat, fv@v2:feat) are used, include the version tag in full_feature_names output so multi-version queries produce distinct columns (fv@v1__feat vs fv@v2__feat). Also fix proto roundtrip test to match -1 sentinel behavior. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat: Handle version race conditions gracefully with retry and forward declaration Auto-increment path (version="latest") now retries up to 3 times on IntegrityError in the SQL registry when concurrent applies race on the same version number. Explicit version path (version="v<N>") now creates the version if it doesn't exist (forward declaration) instead of raising FeatureViewVersionNotFound, with ConcurrentVersionConflict on race. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat: Gate feature services that reference versioned feature views Fail fast at apply time and retrieval time when a feature service references a versioned FV (current_version_number > 0) and enable_online_feature_view_versioning is off. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Resolve mypy errors and rename config field for clarity Rename enable_feature_view_versioning -> enable_online_feature_view_versioning to clarify that it controls online reads, not version history tracking. Fix mypy type narrowing issues with current_version_number (int | None) and variable redefinition in feature_store.py. Remove -1 sentinel from proto serialization in favor of treating proto default 0 without spec.version as None. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat: Enable feature service serving for versioned feature views When enable_online_feature_view_versioning is on and a FeatureService references a versioned FV, set version_tag on the projection so that online reads resolve to the correct versioned table. Previously the FeatureService path never set version_tag, causing reads from the wrong (unversioned) online store table. Changes: - _get_features(): version-qualify feature refs for FeatureService projections - _get_feature_views_to_use(): capture current_version_number before with_projection() discards it, then set version_tag on the projection - feature_store.py: fix mypy type narrowing for the gate check - Add integration tests for both code paths Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * docs: Update RFC for feature service support and rename CLI command Update the Feature Services section in the RFC to reflect that feature services now correctly serve versioned FVs when the online versioning flag is enabled (automatic version_tag resolution on projections). Rename CLI command from `feast feature-views versions` to `feast feature-views list-versions` for consistency, and update all docs references. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat(ui): Add version display and Versions tab to feature view pages Show current version badge in feature view headers and listing table, and add a Versions tab with expandable version history across all feature view types (Regular, Stream, OnDemand). Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * style(ui): Fix prettier formatting in feature view components Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * updated utcnow Signed-off-by: Francisco Javier Arceo <[email protected]> * feat: Add version-aware materialization support Add --version flag to feast materialize/materialize-incremental CLI commands and corresponding Python SDK support. Gate versioned table IDs behind enable_online_feature_view_versioning config flag in SQLite online store. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Resolve three versioning regressions from review feedback 1. Stop injecting version_tag on FeatureService projections in utils.py, which was causing non-SQLite stores to reject FeatureService reads when versioning was enabled. 2. Persist version_tag in FeatureViewProjection proto (field 10) so it survives registry round-trips. 3. Fix _update_metadata_fields() to reset current_version_number to 0 when unpinning a feature view back to version="latest". Update tests to match new behavior and add test_unpin_from_versioned_to_latest. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * feat: Add --no-promote flag to feast apply and fix versioned ref parsing Add --no-promote flag that saves new version snapshots without promoting them to active, enabling phased rollouts without a transition window where unversioned consumers briefly see the new schema. Also audit and fix brittle feature reference parsing across the codebase to properly handle @v<N> version-qualified syntax: - Fix ibis offline store prefix matching to use name_to_use() - Fix Go ParseFeatureReference to strip @v<N> from view name - Fix passthrough_provider saved dataset column naming Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> Signed-off-by: Francisco Javier Arceo <[email protected]> * docs: Consolidate versioning docs into alpha reference page Move detailed versioning documentation from the concepts page into the alpha reference page to avoid duplication. The concepts page now has a brief summary with a link to the full reference. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> Signed-off-by: Francisco Javier Arceo <[email protected]> * docs: Add no_promote to apply_diff_to_registry docstring Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> Signed-off-by: Francisco Javier Arceo <[email protected]> * fix: Reject reserved chars in FV names and make version parser resilient Block `@` and `:` in feature view names via ensure_valid() to prevent ambiguous version-qualified reference parsing. Make _parse_feature_ref() fall back gracefully for legacy FV names containing `@` instead of raising, and update Go's ParseFeatureReference to only strip `@` suffixes matching `v<N>`. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Add ensure_valid() call in Snowflake registry apply_feature_view The Snowflake registry was missing the ensure_valid() call that other registry implementations (SQL, Cask) already perform before applying a feature view. This ensures name validation (including reserved character rejection) runs consistently across all registry backends. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Make version_tag optional in proto and use HasField() for correct zero-value handling The proto field `version_tag` was a plain `int32`, making 0 and "not set" indistinguishable. Changed to `optional int32` so `HasField()` works correctly, and updated `FeatureViewProjection.from_proto` to use it instead of `> 0` which silently dropped version_tag=0. Also removes dead issue link from VersionedOnlineReadNotSupported error. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Address versioning review feedback (Snowflake, Go server, SQL registry) - Snowflake registry: raise NotImplementedError when no_promote=True since versioning is not supported - Go feature server: return error on versioned refs (@vn) instead of silently stripping the version and serving unversioned data - SQL registry: inline delete logic in delete_feature_view so the FV delete and version history cleanup run in a single transaction, preventing orphaned rows on partial failure Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix: Handle @latest in Go feature server and pre-compile version regex - Strip @latest suffix (equivalent to no version) instead of passing through as part of the FV name, which caused confusing "not found" errors - Pre-compile version tag regex to package-level var to avoid recompilation on every call in the hot path Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> --------- Signed-off-by: Francisco Javier Arceo <[email protected]> Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]> Signed-off-by: yuanjun220 <[email protected]>
Summary
Adds automatic version tracking to Feast feature views (
FeatureView,StreamFeatureView,OnDemandFeatureView). Everyfeast applythat changes a feature view's schema or UDF creates a versioned snapshot in the registry. Users can list version history, pin serving to a prior version, query specific versions via@v<N>syntax, and stage new versions without promoting them.Resolves #2728
Key Features
FeatureView(name="driver_stats", version="v2")driver_stats@v2:trips_today(SQLite online store)--no-promote) —feast apply --no-promotesaves a new version without promoting it to active, enabling phased rollouts without a transition windowfeast materialize --views fv --version v2targets a specific version's online store tableenable_online_feature_view_versioningis enabledversionis optional; omitting it is identical toversion="latest"Changes
Proto layer:
FeatureViewVersion.protowithFeatureViewVersionRecord/FeatureViewVersionHistoryversionfield toFeatureViewSpec,StreamFeatureViewSpec,OnDemandFeatureViewSpeccurrent_version_numberto meta messages,version_tagtoFeatureViewProjectionfeature_view_version_historytoRegistryprotoPython SDK — core versioning:
version_utils.py— parses"latest","v2","version2"(case-insensitive)versionparameter onFeatureView,StreamFeatureView,OnDemandFeatureViewapply_feature_viewin file registry, SQL registry (with concurrent apply retry)list_feature_view_versions(name, project)on registries andFeatureStoreget_feature_view_by_version(name, project, version_number)for explicit version lookup_schema_or_udf_changed()to distinguish version-significant changes from metadata updatesPython SDK —
--no-promoteflag:feast apply --no-promoteCLI option threaded throughapply_total()→apply_total_with_repo_instance()→store.apply()/store._apply_diffs()→registry.apply_feature_view()store.apply([...], no_promote=True)Python SDK — version-qualified reads:
_parse_feature_ref()and_strip_version_from_ref()utilities forfv@v<N>:featureparsing@v<N>syntaxversion_tagon projectionsPython SDK — feature ref parsing audit & fixes:
name_to_use()for versioned refspassthrough_provider.pysaved dataset column naming to strip@v<N>ParseFeatureReferenceto strip@v<N>from feature view nameCLI:
feast feature-views versions <name>— list version historyfeast apply --no-promote— stage versions without promotingfeast materialize --views <name> --version v<N>— version-aware materializationUI:
Documentation:
docs/rfcs/feature-view-versioning.md— full design, concurrency, feature services, staged publishingdocs/reference/alpha-feature-view-versioning.md[Alpha] VersioningsectionTest plan
--no-promote(5 tests)UI Preview
🤖 Generated with Claude Code