Skip to main content

Share

You can provide configuration to Snowflake Object Lifecycle Engine for the following operations with shares:

  • Manage the lifecycle of new and existing shares
  • Manage the lifecycle of a cloned share

Usage

shares:
<share-name>:
<configuration-key>: <value>
accounts:
- <organisation-name>.<account-name>

Share creation workflow

When you create a share using the SOLE config file, SOLE creates a temporary database that is usually empty. If the pipeline succeeds, the database is deleted automatically. But, if the pipeline fails after you create the share, the database will remain in your Snowflake instance until you delete it manually. This is expected behavior, and dropping the temp database is safe as it will not affect your development environment or production data.

If you see a temp database with a name like TEMP_<database_name> in your Snowflake instance, it indicates you had a Shares job that failed at some point and should delete manually.

Supported parameters

The engine supports the parameters listed below.

Configuration KeyRequired/OptionalData Types and ValuesDescription
accountsOptionalList of StringA list of accounts to be added to the share
environmentOptionalStringSpecifies the environment in which the Share is managed. Regex can be provided as well
commentOptionalStringSpecifies a comment for the share
deletedOptionalBoolean: True enables deletion prevention, False does nothingSpecifies what objects are allowed to be deleted
manage_modeOptionalString: all (default), noneConfigures what properties to manage for the share.
See Changing Manage Mode before changing the value.
namespacingOptionalString: both (default), prefix, suffix, noneSpecifies whether prefix or suffix or both are to be added to share name [doesn't apply to default database]
share_restrictionsOptionalBooleanEnables or disables adding a standard or enterprise consumer account to a share belonging to a business-critical data provider. You must set this parameter each time you are adding a new non-business critical consumer account to the share belonging to a business-critical provider.

Examples

Share creation

shares:
DEV_SHARE:
comment: "share for Ingestion Developers"

Share with grants to accounts

shares:
MODELLING_SHARE:
comment: "share for Ingestion Developers"
accounts:
- <organisation-name>.<account-name>
- <organisation-name>.<account-name>
warning

It is not possible to grant access to the share for the account the share belongs to. Setting <account-name> to the current account will throw an error.

Revoking accounts from a share

SOLE generates all object grants and revokes based on what you define in the Snowflake object configuration. It looks at the configuration and updates the object to match the configuration.

If the accounts key is defined in a share, SOLE looks at the object configuration and grants access to the share only for the accounts listed in the configuration. Any account granted access to the share outside SOLE will stop having access.

In the same way, if the accounts key isn't defined in a share, SOLE doesn't revoke the accounts from the share if they are added through Snowflake for example. In such a case, SOLE logs that revokes have to be performed but it doesn't do anything. Revokes are only performed if you define a list of accounts. SOLE uses this list to ensure that values in Snowflake match what you have defined in the object configuration.

You can define an empty list in the Snowflake object configuration to revoke all accounts set on the share, including those defined outside SOLE, as the following example shows:

shares:
SHARE_1:
comment: "Share 1"
accounts: []
info

Use the string "---REMOVE_ALL_ACCOUNTS---" to revoke all account logs.

Share with defined share_restrictions

shares:
MODELLING_SHARE:
comment: "share for Ingestion Developers"
accounts:
- <organisation-name>.<account-name>
- <organisation-name>.<account-name>
share_restrictions: false