You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Materialization fails when field mappings are used to rename entity join keys (SnowflakeSource) #5942
Features materialized to online store successfully, with features persisted on the online store using field_mappingvalues for the entity join key as names.
Current Behavior
Materialization fails before the offline store is queried: KeyError: Index(['USERID'], dtype='object')
Only tested on SnowflakeSource
Steps to reproduce
Define a feature source as
createviewschema_name.test as (
selectcurrent_timestamp() as EVENT_TIMESTAMP,
1as USERID,
0.75as FEATURE_1,
300as FEATURE_2
);
get_historical_features already works with the above configuration. Materialization not working in the same way causes inconsistent and confusing behavior.
Using user_id (field_mapping value) as an input to get_historical_features) The offline store is queried with "USERID" (field_mapping key), and the return value once again contains user_id.
Discussion
join_keys arg when defining an Entity already provides a way to map offline store column names to feast registry field/key names, for entity keys. If this is considered the de facto way to manage source column names, than this issue can be closed.
However I think its worth exploring. Having the renaming done at entity level means all tables in the offline store needs to use the same column name for that entity key. There might be cases where different teams refer to the same entity with different names, just because the business context is different.
Activity
fix(compute-engine/local): Honor field_mapping on join keys in dedup …
fix(compute-engine/local): Honor field_mapping on join keys in dedup …
feat: Add enabled/disabled toggle for feature views (#6401)