Bundle 2022_07

Unter diesem Thema werden die folgenden in diesem Monat vorgenommenen Verhaltensänderungen (falls vorhanden) beschrieben:

  • Features, die veraltet sind.

  • Gebündelte Änderungen, die aktiviert wurden.

  • Andere, nicht gebündelte Änderungen, die implementiert wurden.

Wenn Sie Fragen zu diesen Änderungen haben, wenden Sie sich an den Snowflake-Support.

Weitere Einzelheiten zu den in diesem Monat eingeführten neuen Features, Erweiterungen und Korrekturen finden Sie unter Oktober 2022.

Wichtig

Sofern nicht anders angegeben, sind diese Änderungen in Bundle 2022_07 enthalten, das standardmäßig mit Release 6.35 aktiviert wurde.

Unter diesem Thema:

SQL-Änderungen – Befehle und Funktionen

Datenbanken und Schemas: Löschen oder Ersetzen nicht erlaubt, wenn dies zu „Verwaiste Referenzen“ bei Richtlinien und Tags führt

Das Verhalten der Operationen zum Löschen oder Ersetzen einer Datenbank/eines Schemas in Bezug auf eine Maskierungsrichtlinie, ein Tag oder eine geschützte Spalte in einer Tabelle hat sich wie folgt geändert:

Bisher

Wenn sich Tag und Richtlinie in demselben Schema befinden, aber die Tabelle in einem anderen Schema, hat Snowflake die Operationen DROP und REPLACE für das Schema bzw. die Datenbank zugelassen, in denen sich Tag und Maskierungsrichtlinie befanden, wenn sich die geschützte Spalte der Tabelle in einem anderen Schema bzw. einer anderen Datenbank befand.

Das Verhalten galt für die folgenden vier Befehle:

Jetzt

Wenn das gleiche Szenario jetzt auftritt, lässt Snowflake die Operationen DROP und REPLACE für das Schema/die Datenbank, in denen sich Tag und Maskierungsrichtlinie befinden, nicht zu, wenn sich die geschützte Spalte der Tabelle in einem anderen Schema bzw. einer anderen Datenbank befindet.

Infolgedessen hat sich das Verhalten der vier oben genannten Befehle geändert.

Beispiel:

  • Ein Tag mit dem Namen t1 und eine Maskierungsrichtlinie mit dem Namen p1 existieren in dem Schema mit dem Namen governance.tags.

  • Die Maskierungsrichtlinie p1 wird dem Tag t1 zugewiesen (d. h. Tag-basierte Maskierungsrichtlinie).

  • Das Tag t1 ist einer Tabelle namens finance.accounting.customers zugewiesen.

Bisher erlaubte Snowflake die Operation DROP SCHEMA für das Schema governance.tags und die Operation DROP DATABASE für die Datenbank governance, während das Tag t1 der Tabelle finance.accounting.customers zugewiesen war.

Nun lässt Snowflake keine der beiden Operationen zu, solange das Tag t1 der Tabelle zugewiesen ist. Je nach versuchter Operation gibt Snowflake eine der folgenden Fehlermeldungen zurück:

  • DROP DATABASE und CREATE OR REPLACE DATABASE:

    Cannot drop or replace database because: Tag governance.tags.tag1 used by schema finance.accounting in another database

  • DROP SCHEMA und CREATE OR REPLACE SCHEMA:

    Cannot drop or replace schema because: Tag governance.tags.tag1 used by another schema finance.accounting

Befehl CREATE MATERIALIZED VIEW: Time Travel-Klauseln sind nicht mehr erlaubt

Eine Einschränkung für materialisierte Ansichten besteht darin, dass Time Travel nicht unterstützt wird. Beim Ausführen des Befehls CREATE MATERIALIZED VIEW war es jedoch möglich, eine Time Travel-Klausel (z. B. AT) für die Basistabelle der Ansicht anzugeben.

Die Angabe einer Time Travel-Klausel in CREATE MATERIALIZED VIEW führt jetzt zu einem Fehler.

Bisher

Die Angabe einer Time Travel-Klausel in CREATE MATERIALIZED VIEW führte nicht zu einem Fehler.

Die folgenden Anweisungen wurden zum Beispiel erfolgreich und ohne Fehlermeldung ausgeführt:

  • Beispiel 1:

    create or replace materialized view mv as select * from basetbl at(offset => -2);
    
    Copy
  • Beispiel 2:

    create or replace materialized view mv as select * from basetbl at(timestamp => $ts);
    
    Copy
  • Beispiel 3:

    create or replace materialized view mv as select * from basetbl at(statement => $uuid_dml);
    
    Copy
Jetzt

Die Angabe einer Time Travel-Klausel in CREATE MATERIALIZED VIEW führt nun zu folgender Fehlermeldung:

002274 (42601): SQL compilation error: Invalid materialized view: Time travel on base table in line X at position Y.

SQL-Änderungen – Nutzungsansichten & Information Schema-Ansichten/Tabellenfunktionen

Ansicht GRANT_TO_ROLES (Account Usage): Änderungen an der Ansicht

Die folgenden Änderungen wurden an der Ansicht ACCOUNT_USAGE.GRANTS_TO_ROLES vorgenommen.

Bisher

Die Ausgabe der Ansicht enthielt Berechtigungszuweisungen zu Rollen für temporäre Tabellen.

Jetzt

Die Ausgabe der Ansicht enthält keine Berechtigungszuweisungen zu Rollen für temporäre Tabellen.

Änderungen bei Data Lakes

Befehl CREATE EXTERNAL TABLE: Benutzerdefinierte Partitionen und automatisch aktualisierte Metadaten

Wenn Sie die Partitionen in einer externen Tabelle als benutzerspezifisch definieren, können Sie Partitionen selektiv hinzufügen und entfernen, anstatt automatisch Partitionen für alle neuen Dateien an einem externen Speicherort hinzuzufügen, die einem Ausdruck entsprechen. Dieser Partitionstyp wird beim Erstellen einer externen Tabelle durch Einfügen des Parameters PARTITION_TYPE = USER_SPECIFIED angegeben. Die benutzerdefinierte Partitionierung unterstützt nicht die automatische Aktualisierung der Metadaten externer Tabellen.

Wenn eine CREATE EXTERNAL TABLE-Anweisung mit den beiden Parametern PARTITION_TYPE = USER_SPECIFIED und AUTO_REFRESH = TRUE ausgeführt wird, hat sich das Verhalten wie folgt geändert:

Bisher

Die CREATE EXTERNAL TABLE-Anweisung war erfolgreich, aber alle Ereignisbenachrichtigungen, die vom Cloudspeicher für die externe Tabelle empfangen wurden (z. B. Meldung „neues Objekt“), führten zu einem Fehler.

Jetzt

Die Anweisung CREATE EXTERNAL TABLE gibt einen Benutzerfehler zurück.

Funktion GET_DDL: Gibt den Parameter TABLE_FORMAT für externe Tabellen im Delta Lake zurück

Wenn die Eingabe für die Funktion GET_DDL eine externe Tabelle ist, die auf eine Delta Lake-Tabelle verweist, hat sich die von der Funktion zurückgegebene CREATE EXTERNAL TABLE-Anweisung wie folgt geändert:

Bisher

In der Anweisung fehlte der Parameter TABLE_FORMAT = DELTA, der die externe Tabelle als Verweis auf eine Delta Lake-Tabelle identifiziert.

Jetzt

Die Anweisung enthält den Parameter TABLE_FORMAT = DELTA.

Änderungen an der Erweiterbarkeit

Snowpark für Python: Gibt Fehler früher zurück, wenn ungültige Pakete hinzugefügt werden

Beim Hinzufügen eines Python-Pakets zu einer Python-Sitzung in Snowpark erhält der Benutzer eine Fehlermeldung, wenn das Paket oder die angegebene Version nicht von Snowflake unterstützt wird.

Der Zeitpunkt, zu dem die Fehlermeldung ausgegeben wird, wurde auf einen früheren Zeitpunkt verlegt:

Bisher

Der Fehler wurde nur ausgegeben, wenn der Benutzer versuchte, eine UDF oder eine gespeicherte Prozedur zu registrieren.

Jetzt

Der Fehler tritt früher auf, wenn „add_packages“ verwendet wird, um das Python-Paket hinzuzufügen.

Der Aufruf von "session.add_packages('numpy==21.21.21')" führt zum Beispiel zu "ValueError", da die Paketversion ungültig ist.

Snowpark für Scala und Java: Änderung der Typen von Elemente in DeleteResult, MergeResult und UpdateResult

In den Snowpark Scala- und Java-APIs stellen die Klassen DeleteResult, MergeResult und UpdateResult die Wertelemente bzw. Get-Methoden bereit, die die Anzahl der eingefügten, aktualisierten und gelöschten Zeilen zurückgeben:

  • In der Snowpark Scala-API sind das die folgenden Wertelemente:

    • rowsInserted

    • multiJoinedRowsUpdated

    • rowsUpdated

    • rowsDeleted

  • In der Snowpark Java-API sind das die folgenden Get-Methoden:

    • getRowsInserted

    • getMultiJoinedRowsUpdated

    • getRowsUpdated

    • getRowsDeleted

In der Version 1.7.0 der Snowpark Library für Scala und Java haben sich die Typen dieser Wertelemente und die Rückgabetypen dieser Get-Methoden geändert:

Vor 1.7.0
  • In der Scala-API heißt der Typ Int.

  • In der Java-API heißt der Typ int.

Ab 1.7.0
  • In der Scala-API heißt der Typ Long.

  • In der Java-API heißt der Typ long.