René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Enforce unique feature view names across all feature view types during apply","articleBody":"## Problem\n\nIn the Feast Python SDK, `get_online_features` resolves feature view names through `_get_any_feature_view`, which checks the registry tables in a fixed order:\n\n1. Regular `FeatureView`\n2. `OnDemandFeatureView`\n3. `StreamFeatureView`\n\nThis means if a project registers both a regular `FeatureView` and a `StreamFeatureView` (or `OnDemandFeatureView`) sharing the same name, `get_online_features` will always return the regular feature view — even if the stream view is the one producing the freshest data.\n\n### Relevant code\n\n**`SqlRegistry._get_any_feature_view`** ([sql.py#L374-L409](https://github.com/feast-dev/feast/blob/master/sdk/python/feast/infra/registry/sql.py#L374-L409)):\n```python\ndef _get_any_feature_view(self, name: str, project: str) -\u003e BaseFeatureView:\n    fv = self._get_object(table=feature_views, ...)\n    if not fv:\n        fv = self._get_object(table=on_demand_feature_views, ...)\n    if not fv:\n        fv = self._get_object(table=stream_feature_views, ...)\n    return fv\n```\n\n**`proto_registry_utils.get_any_feature_view`** follows the same fixed-order pattern for the cached registry path.\n\n### Same pattern in `FeatureStore.apply`\n\nDuring `apply`, the different feature view types are separated into independent lists (`views_to_update`, `sfvs_to_update`, `odfvs_to_update`) and applied independently — there is no cross-type uniqueness check on names.\n\n## Expected Behavior\n\n`feast apply` should **fail with a clear error** if a feature view name collides across different feature view types (e.g., a `FeatureView` and a `StreamFeatureView` sharing the same name). This would prevent silent, hard-to-debug issues at serving time.\n\n## Proposed Solution\n\nAdd a validation step in `FeatureStore.apply()` (or `_validate_feature_views`) that collects all feature view names across `FeatureView`, `OnDemandFeatureView`, and `StreamFeatureView`, and raises a `ValueError` if any duplicates are found.\n\n### Implementation guidance\n\n1. **Where to add the check**: In `FeatureStore.apply()` ([feature_store.py#L770](https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature_store.py#L770)), after the objects are separated into `views_to_update`, `sfvs_to_update`, and `odfvs_to_update` (around line 849), add a cross-type name uniqueness validation.\n\n2. **What the check should do**:\n   - Collect all names from `views_to_update`, `sfvs_to_update`, and `odfvs_to_update`\n   - Detect any duplicate names across these lists\n   - Raise a clear `ValueError` listing the duplicated name(s) and which types collide\n\n3. **Alternatively or additionally**, the `_validate_feature_views` method ([feature_store.py#L560-L579](https://github.com/feast-dev/feast/blob/master/sdk/python/feast/feature_store.py#L560-L579)) could be extended to include this cross-type check.\n\n4. **Tests**: Add unit tests that verify `apply` raises an error when feature views of different types share the same name.\n\n## References\n\n- Discussed in Feast Slack #feast-beginners: [thread](https://feastopensource.slack.com/archives/C01MSKCMB37/p1770637394216179)","author":{"url":"https://github.com/devin-ai-integration[bot]","@type":"Person","name":"devin-ai-integration[bot]"},"datePublished":"2026-02-20T05:24:55.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/5995/feast/issues/5995"}