Registering data¶
This topic describes how to register data so that it can be linked into a Snowflake Data Clean Room.
Supported objects¶
Different types of objects can be linked into a clean room depending on whether the clean room was created using the web application or the clean room API:
- Web app clean rooms:
Clean rooms created using the Snowflake Data Clean Rooms web application can link the following objects into their dataset:
Tables
Dynamic tables
Views
Materialized views
Secure views. The owner of a secure view must be the SAMOOHA_APP_ROLE role.
- API clean rooms:
Clean rooms created using the clean room API can link any object supported by the Snowflake Native App Framework.
Note
External and Iceberg tables must be enabled before they can be registered.
Registering data objects¶
Before users can link data into a clean room, the data must first be registered at the database, schema, or object level. Registering data grants USAGE and SELECT privileges on the object to SAMOOHA_APP_ROLE, which is used by the clean room environment to access data. Registering a database or schema registers all of the objects in that database or schema.
Important
Registering a database or schema does not register objects added after the registration. You must either register the new object individually or use the web app to navigate to Admin > Snowflake Admin > Database Registration and select Resync.
You can link only data that has been registered in your account. That is, a provider can link only data registered in the provider account and a consumer can link only data registered in the consumer’s account. All parties can access data linked into their account by any party, subject to the data owner’s settings (permitted templates, join and column policies, and so on).
You can register objects in code or using the web app. Using the web app is simpler, but requires that you have the ACCOUNTADMIN role. With the clean room API, any object owner can register it even if they are not an account administrator.
Registering an object grants access to that object by the SAMOOHA_APP_ROLE role, which the native application uses to access the object.
Follow the steps below to register a database, schema, or object using the web application:
Sign in to the web app as an account administrator and then take one of the following steps:
If using a managed account, select Admin > My Account.
If using a Snowflake account, select Admin > Snowflake Admin and sign in to Snowflake as a user with the ACCOUNTADMIN role.
Select Admin > Snowflake Admin.
Select Log in to Snowflake, and authenticate as a user with the ACCOUNTADMIN role.
To enable external or Iceberg tables in the account, enable the External & Iceberg Tables toggle.
In the Access management for Snowflake objects section, select Edit, and then select the database, schema, or object to make its data linkable by users in this account.
Select Save.
Use the clean room API to register databases, schemas, and objects programmatically. Note that you need MANAGE GRANTS privilege on an object to register it.
External and Iceberg tables are registered differently than other object types.
The following procedures are available to register or unregister objects:
Object type |
Register |
Unregister |
|---|---|---|
Database |
|
|
Schema |
|
|
Managed access schema |
|
|
Any other supported object type |
|
|
Example:
CALL samooha_by_snowflake_local_db.library.register_schema(['MY_DB.MY_SCHEMA']);
Enabling external and Apache Iceberg™ tables¶
To allow external tables and Iceberg tables to be linked into a clean room, the account must first be configured to to enable use of external and Iceberg tables. After external and Iceberg tables are enabled, they can be registered, linked, and used the same as any other tables.
The process for enabling external and Iceberg tables varies, depending on whether you are managing the clean room in the web app or in code.
External and Iceberg table requirements¶
Both the provider and consumer accounts must enable external and Iceberg tables to allow full usage of a clean room that links in external or Iceberg tables.
Providers must always enable external tables and Iceberg tables when sharing a clean room with a managed account. This is because managed accounts always use external tables.
If the provider and consumer are in different regions, only the consumer can link external or Iceberg tables into a clean room.
The web app controls external and Iceberg tables at the account level.
Warning
If the consumer account has not enabled this feature, consumers will be blocked from joining any clean rooms that link in external or Iceberg tables, or will be prevented from editing (but can still run) any already joined clean rooms that link in either type of table.
A DCR administrator in both the provider and consumer accounts must take the following steps:
Sign in to the web app as an account administrator and then take one of the following steps:
If using a managed account, select Admin > My Account.
If using a Snowflake account, select Admin > Snowflake Admin and sign in to Snowflake as a user with the ACCOUNTADMIN role.
Enable the External & Iceberg Tables toggle. This enables the feature in both web app and code-created clean rooms.
External and Iceberg tables are now selectable in the administrator’s Access management for Snowflake objects panel, where they can be selected to make them available to clean rooms, the same as any other objects.
In code, you must enable external and Iceberg tables at both the account level and also for each clean room that links in external or Iceberg tables. If you have enabled external and Iceberg tables in the web application, you do not need to enable them in code (you don’t need to take the steps listed here).
Warning
If only one account has enabled this feature for their account or clean room and linked in an external or Iceberg table, the other account will be able to run existing templates, but won’t be able to modify the clean room in any way until external and Iceberg tables are allowed in both that account and clean room.
To enable and use external or Iceberg tables for new clean rooms in code:
A user with the ACCOUNTADMIN role first enables external and Iceberg tables for the entire clean room environment in both the provider and consumer accounts:
USE ROLE ACCOUNTADMIN; CALL samooha_by_snowflake_local_db.library.enable_external_tables_on_account();
Note
Existing clean rooms created in the web app are not affected by this method. To update existing clean rooms created in the web app you must either enable them in code individually, as shown in the next steps, or else enable clean rooms using the web app, which enables the feature for all existing clean rooms.
A provider enables external and Iceberg tables for their clean room. Note that this triggers a security scan which, if successful, will generate a new clean room version, so you will need to update the default release directive.
USE ROLE SAMOOHA_APP_ROLE; CALL samooha_by_snowflake_local_db.provider.enable_external_tables_for_cleanroom( $cleanroom_name); -- Call until scan is complete. call samooha_by_snowflake_local_db.provider.view_cleanroom_scan_status($cleanroom_name); -- When scan is successful, update with patch version mentioned in return value from enable_external_tables_for_cleanroom. call samooha_by_snowflake_local_db.provider.set_default_release_directive($cleanroom_name, 'V1_0', '<PATCH_VERSION>');
A consumer must also enable use of external and Iceberg tables in the same clean room:
USE ROLE SAMOOHA_APP_ROLE; CALL samooha_by_snowflake_local_db.consumer.enable_external_tables_for_cleanroom( $cleanroom_name);
After external and Iceberg tables have been enabled for a clean room, collaborators can register and link these tables the same way as any other table.