2021_08 Bundle¶

SHOW NETWORK POLICIES Command: Verify Authorization¶

The SHOW NETWORK POLICIES command has changed as follows:

Previously

The output of the SHOW NETWORK POLICIES included all network policies, regardless of the privileges held by the active role.

Currently

The output of SHOW NETWORK POLICIES shows only those policies for which the active role holds the OWNERSHIP privilege unless the active role has been granted the MANAGE GRANTS privilege, in which case all policies are returned.

New Web Interface: Client Sessions Limited to 4 Hours of Inactivity¶

With continued user activity, a client session is maintained indefinitely. After a period of inactivity, the session is terminated and the user is forced to log in again.

For users logged into the new web interface, this period of inactivity has changed as follows:

Previously

The session terminated 2 weeks after the user logged in.

Currently

The session terminates after 4 hours of inactivity.

This change aligns the behavior of the new web interface with the security requirements of many accounts.

Parameters Set on Source Object are Retained in Cloned Object¶

When an object is cloned, any parameters that are explicitly set on the object or its children are now retained consistently in any object clones.

Previously

Parameters set at the object level were handled inconsistently when cloning the container (database or schema) or child objects (schema or table).

Currently

Parameters set on a source database, schema, or table are retained consistently in any clones created from the source container or child objects.

Replication: Additional Parameters Replicated to Secondary Databases¶

Database replication currently only replicates the DATA_RETENTION_TIME_IN_DAYS parameter for objects from the primary database to the secondary database.

Additional object parameters that can be set by users are now also replicated to the secondary database.

Previously

Database replication only replicated the DATA_RETENTION_TIME_IN_DAYS parameter for objects to secondary databases.

Currently

Database replication replicates the following parameters to objects in the secondary databases:

• DATA_RETENTION_TIME_IN_DAYS

• DEFAULT_DDL_COLLATION

• MAX_DATA_EXTENSION_TIME_IN_DAYS

• PIPE_EXECUTION_PAUSED

• QUOTED_IDENTIFIERS_IGNORE_CASE

DESCRIBE PIPE / SHOW PIPES Commands: New ERROR_INTEGRATION Column in Output¶

The output of the DESCRIBE PIPE and SHOW PIPES commands now includes a new ERROR_INTEGRATION column.

For pipes that rely on notification error events in Amazon S3 cloud storage to trigger notifications, the column displays the notification integration name.

Data Marketplace / Data Exchange: Consumers Must Provide Contact Information Before Creating a Database from a Share¶

The following change has been introduced for Snowflake Data Marketplace and data exchange consumers attempting to create a database from a share attached to standard listing:

Previously

Consumers were allowed to create a database from a share attached to a standard listing without providing personal contact information, such as a first name, last name, or email address.

Currently

Consumers are required to provide a first name, last name, and an email address before they can create a database from a share attached to a standard listing. This information must be added via the user’s profile.

Snowpark Library 0.10.0: Scala API No Longer Includes APIs Intended for Use in Java¶

Previous releases of the Snowpark library for Scala included APIs that were intended only for use in Java (not Scala). For example, some Scala API methods returned Java types.

In the Snowpark library release 0.10.0, these APIs have been removed:

Previously

The Snowpark library JAR file and scaladoc included APIs intended for use only in Java (not in Scala).

For example, the library included methods that returned java.util.List (rather than Seq).

Currently

The Snowpark library JAR file and scaladoc do not include the APIs intended for use only in Java.

Snowpark Library 0.10.0: log4j Replaced By SLF4J SimpleLogger¶

The Snowpark library 0.10.0 removes the dependency on the log4j libraries. With this change:

• The library uses the SLF4J API for logging.

  You can configure your application to use any type of logger that is compatible with the SLF4J API.

• If you have not configured your application to use a specific type of logger, the library uses a SimpleLogger class for logging by default.

  SimpleLogger is one of the logger implementations provided with SLF4J. For more details, see Where can I get a particular SLF4J provider/binding in the SLF4J FAQ.

This change can affect the way in which you configure your logger and call APis for logging:

Previously

The Snowpark library depended on the log4j classes.

To configure your logger, you could use either a log4j.properties file or the log4j APIs.

Currently

The Snowpark library no longer depends on the log4j classes.

As a result:

• The Snowpark library no longer recognizes the log4j.properties file.

  If you have not configured Snowpark to use a specific type of logger, the Snowpark library uses SimpleLogger, which you can configure by using a simplelogger.properties file.

• The log4j classes are no longer provided.

If you are using the log4j APIs in your code, you might encounter an error that reports that the log4j classes could not be found. Instead, use the SLF4J classes.

For example, if you want to use the SimpleLogger provided by default and you want to change the log level to DEBUG (from the default level of INFO), you can create a simplelogger.properties file containing the following line and include that file in your classpath:

# Set the default log level for the SimpleLogger to DEBUG.
org.slf4j.simpleLogger.defaultLogLevel=debug