| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
get_user_metadata was filtering only by feature view name, allowing a
shared Snowflake registry to return user metadata from a different
project's feature view with the same name. Added project_id = '{project}'
to the WHERE clause, consistent with apply_user_metadata.
delete_project was interpolating a Project object into the SQL string
instead of the project name string, which would use __str__ of the object
rather than the actual name. Changed to use the `name` parameter directly.
Signed-off-by: Abhishek8108 <87538407+Abhishek8108@users.noreply.github.com>
| Back | FazBrowse Home | New Git URL |
Summary
Two pre-existing SQL correctness bugs in SnowflakeRegistry, noticed while working on #6243.
get_user_metadata (line 1119)
The SELECT query filtered only by {fv_column_name}_name, without scoping to project_id. The primary key for feature view tables is (feature_view_name, project_id), so in a shared Snowflake registry this could return user metadata from a different project's feature view with the same name. Fixed by adding project_id = '{project}' to the WHERE clause — consistent with apply_user_metadata which already does this correctly.
delete_project (line 1326)
The DELETE query interpolated project, which is a Project object returned by self.get_project(name). Project.__str__ returns str(MessageToJson(self.to_proto())) — a JSON blob — which never matches any project_id stored in the database. This made delete_project a silent no-op: all DELETE statements executed successfully but matched zero rows. Fixed by using the name string parameter directly.
Testing
Both are SQL correctness fixes. The existing integration test suite in test_universal_registry.py covers both methods end-to-end; no new unit test surface is introduced by these changes.
Relates to #6243.