Current Behavior
In case of SQLite online store + shared registry scenario, the update() logic has bug: It deletes tables based on the tables_to_delete list without considering that those tables might belong to other projects.
Created entity driver
Created feature view driver_hourly_stats_fresh
Created feature view driver_hourly_stats
Created on demand feature view transformed_conv_rate
Created on demand feature view transformed_conv_rate_fresh
Created feature service driver_activity_v1
Created feature service driver_activity_v2
Created feature service driver_activity_v3
Created sqlite table demo_driver_hourly_stats_fresh
Created sqlite table demo_driver_hourly_stats
Deleted sqlite table credit_credit_history
Deleted sqlite table credit_loan_features
Deleted sqlite table credit_person_demographics
Deleted sqlite table credit_zipcode_features
Steps to reproduce
- Set up two projects using shared SQL registry
- Deploy feature views in both projects:
demo project: driver_hourly_stats
example project: credit_history, loan_features
- Run feast apply in the demo project
- Observe that SQLite tables from example project are deleted.
Current Behavior
In case of SQLite online store + shared registry scenario, the
update()logic has bug: It deletes tables based on thetables_to_deletelist without considering that those tables might belong to other projects.Steps to reproduce
demo project: driver_hourly_stats
example project: credit_history, loan_features