Verwenden Sie ein versioniertes Schema, um App-Objekte versionsübergreifend zu verwalten¶

Über versionierte Schemas¶

Versionierte Schemas sind spezielle Arten von Datenbankschemas, die für den Umgang mit zustandslosen Objekten von einer Version zur anderen konzipiert sind.

Ein versioniertes Schema enthält Metadaten über die Objekte in einer App, die mit einer bestimmten Version verbunden sind. Das Anheften der Version ist ein Feature von versionierten Schemas, das es einer App ermöglicht, zu wissen, welche Jobs, Abfragen usw. mit diesen Objekten verbunden sind.

Wenn ein Objekt in einem versionierten Schema beispielsweise eine Abfrage ausführt, wird diese Abfrage an die Version der App „angeheftet“, die die Abfrage ausführt.

Das Anheften der Version ist wichtig, wenn Sie eine App auf eine neue Version aktualisieren. Stellen Sie sich vor, V1 einer Anwendung führt eine komplexe Abfrage aus, die viel Zeit in Anspruch nimmt.

Wenn ein Upgrade stattfindet, während diese Abfrage noch läuft, ändert sich der Upgrade-Status der App auf COMPLETE und die App wird auf v2 aktualisiert. Der Status der vorherigen Version wechselt zu FINALIZING, bis alle Jobs der Version v1 abgeschlossen sind.

Unter Upgrade-Status finden Sie weitere Informationen zu den Upgrade-Status einer App.

Beschränkungen für versionierte Schemas¶

• Snowpark Container Services wird in versionierten Schemas nicht unterstützt.

• Versionierte Schemas sind nur im Kontext eines Anwendungsobjekts verfügbar. Sie werden nur innerhalb des Setup-Skripts erstellt. Jede Version einer App hat ihr eigenes Setup-Skript und enthält ein versioniertes Schema, das für diese Version spezifisch ist.

• Ein versioniertes Schema kann nur innerhalb des Setup-Skripts eines Anwendungspakets verwendet werden. Sie können nur im Zusammenhang mit einem Anwendungsobjekt erstellt werden.

• Aufgaben werden bei versionierten Schemas nicht unterstützt. So können Anbieter beispielsweise keine Tags einfügen, wenn sie ein versioniertes Schema erstellen oder ändern. Anbieter können jedoch Tags innerhalb eines versionierten Schemas verwenden, solange sie diese Tag-Objekte nur innerhalb eines versionierten Schemas in derselben Anwendung anwenden.

• Tags und Maskierungsrichtlinien werden in versionierten Schemas nicht unterstützt.

• Berechtigungen und zukünftige Berechtigungen werden in versionierten Schemas nicht unterstützt.

• Versionierte Schemas können weder als Quelle noch als Ziel eines Klonvorgangs verwendet werden.

• Das Löschen eines versionierten Schemas wird nicht unterstützt. Das Löschen eines versionierten Schemas würde alle Versionen der darin enthaltenen Objekte löschen und sich auf Abfragen auswirken, die gegen ältere Versionen oder Patches der Anwendung laufen.

Interne Implementierung von versionierten Schemas¶

Intern enthalten versionierte Schemas Unterschemas, die jeder Version der App entsprechen.

Diese Teilschemas sind jedoch für den Verbraucher innerhalb des Anwendungsobjekts nicht direkt zugänglich. Ein Verbraucher sieht nur Objekte innerhalb des versionierten Schemas, die der Version der App entsprechen, die er in seinem Konto installiert hat.

Wenn ein Verbraucher beispielsweise den Befehl SHOW OBJECTS verwendet, um die Objekte in einem versionierten Schema anzuzeigen, sieht er nur die Objekte der Version, die er gerade verwendet.

Wenn Sie das Setup-Skript schreiben, müssen Anbieter Objekte in einem versionierten Schema mit CREATE OR REPLACE oder CREATE IF NOT EXISTS neu erstellen. Dies ist wichtig, da intern jede Version der App ihre eigenen Objekte innerhalb des Unterschemas des versionierten Schemas hat.

Verwendung von versionierten und nicht versionierten Schemas im Setup-Skript¶

Um den Status einer App bei Upgrades zu verwalten, verwendet das Snowflake Native App Framework versionierte Schemas. Ein versioniertes Schema ähnelt einem normalen Datenbankschema mit zusätzlicher Funktionalität zur Handhabung mehrerer Versionen von Objekten, die von verschiedenen Anwendungsversionen erstellt wurden.

Versionierte Schemas sind nur im Kontext eines Anwendungsobjekts verfügbar. Sie werden nur innerhalb des Setup-Skripts erstellt. Jede Version einer App hat ihr eigenes Setup-Skript und enthält ein versioniertes Schema, das für diese Version spezifisch ist.

Bei der Entwicklung einer neuen Version einer App müssen Anbieter die Änderungen an den Objekten berücksichtigen, die die App mithilfe des Setup-Skripts erstellt.

Das folgende Beispiel zeigt eine häufige Situation, in der sowohl versionierte als auch normale Schemas in einem Setup-Skript verwendet werden können, um zustandslose und zustandsabhängige Komponenten zu erstellen:

CREATE OR ALTER VERSIONED SCHEMA stateless_objects;
CREATE OR REPLACE PROCEDURE stateless_object.py_echo_proc(STR string)
  RETURNS STRING
  LANGUAGE PYTHON
  RUNTIME_VERSION=3.8
  PACKAGES=('snowflake-snowpark-python')
  HANDLER='echo.echo_proc'
  IMPORTS=('/libraries/echo.py');

CREATE OR ALTER SCHEMA stateful_object;
CREATE TABLE stateful_object.config_props
  prop_name STRING;
  prop_value STRING;
  time_stamp TIMESTAMP;

Ein versioniertes Schema erstellen¶

Um ein versioniertes Schema mit dem Setup-Skript zu erstellen, verwenden Sie den Befehl CREATE OR ALTER VERSIONED SCHEMA wie im folgenden Beispiel gezeigt:

CREATE OR ALTER VERSIONED SCHEMA version_schema;

Verwenden nicht versionierter Schemas für zustandsabhängige Objekte¶

Objekte innerhalb einer Anwendung müssen möglicherweise ihren Zustand über mehrere Versionen hinweg beibehalten. So können beispielsweise Konfigurationsdaten oder Daten, die während der Ausführung der App gesammelt wurden, aufbewahrt werden.

Diese Objekttypen müssen sich in einem normalen Datenbankschema befinden und sollten so erstellt werden, dass sie bei der Erstinstallation und bei Upgrades erhalten bleiben.

Das folgende Beispiel zeigt, wie Sie ein zustandsabhängiges Objekt im Setup-Skript erstellen:

CREATE SCHEMA IF NOT EXISTS stateful_object;

CREATE TABLE IF NOT EXISTS stateful_object.config (
  config_param STRING,
  config_value STRING,
  default_value STRING,
  modified_on  TIMESTAMP);

ALTER TABLE stateful_object.config
  ADD COLUMN IF NOT EXISTS modified_on TIMESTAMP;

In diesem Beispiel definiert das Setup-Skript eine Konfigurationstabelle, die von einer Version einer App zur anderen bestehen bleibt. Wenn die vorherige Version der Anwendung nicht über eine modified_on-Spalte verfügte, versucht das Setup-Skript zunächst, die Tabelle vollständig zu erstellen (im Falle einer Erstinstallation) oder die bestehende Tabelle durch Hinzufügen der Spalte zu ändern (im Falle eines Upgrades).

Verwenden versionierter Schemas für zustandslose Objekte¶

Einige Objekte innerhalb einer Anwendung behalten ihren Zustand zwischen verschiedenen Versionen einer Anwendung nicht bei. So kann beispielsweise der Code, der die Anwendungslogik definiert, einschließlich gespeicherter Prozeduren, Funktionen usw., im Setup-Skript vollständig neu erstellt werden, ohne dass Benutzerdaten oder der Status verloren gehen.

Snowflake empfiehlt, dass diese Objekte in einem versionierten Schema enthalten sind.

Das folgende Beispiel zeigt, wie Sie eine UDF innerhalb eines versionierten Schemas erstellen.

CREATE OR ALTER VERSIONED SCHEMA stateless_object;
CREATE FUNCTION IF NOT EXISTS stateless_object.add(x int, y int)
  RETURNS INT
  LANGUAGE SQL
  AS $$ x + y $$;

Version anheften¶

Ein versioniertes Schema enthält Metadaten darüber, welche Objekte in einer Snowflake Native App mit einer bestimmten Version verbunden sind. Das Anheften der Version ist ein Feature von versionierten Schemas, das es einer App ermöglicht, zu wissen, welche Jobs, Abfragen usw. mit diesen Objekten verbunden sind.

Wenn ein Objekt in einem versionierten Schema beispielsweise eine Abfrage ausführt, wird diese Abfrage an die Version der App „angeheftet“, die die Abfrage ausführt.

Das Anheften der Version ist wichtig, wenn Sie eine App auf eine neue Version aktualisieren. Stellen Sie sich vor, V1 einer Anwendung führt eine komplexe Abfrage aus, die viel Zeit in Anspruch nimmt. Wenn eine Aktualisierung erfolgt, während diese Abfrage noch läuft, wird die App erst aktualisiert, wenn die Abfrage abgeschlossen ist.