This topic describes the following behavior changes (if any) for the month:
Features that were deprecated.
Bundled changes that were enabled.
Other, non-bundled changes that were implemented.
If you have any questions about these changes, please contact Snowflake Support.
For details about the new features, enhancements, and fixes introduced this month, see Oktober 2021.
Unless otherwise noted, these changes are contained in the 2021_08 bundle, which was enabled by default in the 5.37 release update.
In this Topic:
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:
The session terminated 2 weeks after the user logged in.
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.
SQL Changes — General¶
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.
Parameters set at the object level were handled inconsistently when cloning the container (database or schema) or child objects (schema or table).
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.
Database replication only replicated the DATA_RETENTION_TIME_IN_DAYS parameter for objects to secondary databases.
Database replication replicates the following parameters to objects in the secondary databases:
Parameters set for the database are not replicated.
SQL Changes — Commands & Functions¶
DESCRIBE PIPE / SHOW PIPES Commands: New ERROR_INTEGRATION Column in Output¶
For pipes that rely on notification error events in Amazon S3 cloud storage to trigger notifications, the column displays the notification integration name.
Data Sharing Changes¶
Other Implemented Changes¶
This section describes changes implemented this month that were not included in any behavior change bundle.
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:
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
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.
SimpleLoggeris 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:
The Snowpark library depended on the log4j classes.
To configure your logger, you could use either a
log4j.propertiesfile or the log4j APIs.
The Snowpark library no longer depends on the
As a result:
The Snowpark library no longer recognizes the
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