Utiliser un schéma versionné pour gérer les objets de l’application entre les différentes versions¶

À propos des schémas en version¶

Les schémas par version sont des types particuliers de schémas de base de données conçus pour gérer des objets sans état d’une version à l’autre.

Un schéma versionné contient des métadonnées sur les objets d’une application qui sont associés à une version spécifique. L’épinglage de version est une fonction des schémas versionnés qui permet à une application de savoir quels tâches, requêtes, etc. sont associés à ces objets.

Lorsqu’un objet d’un schéma versionné exécute une requête, par exemple, cette requête est « épinglée » à la version de l’application qui exécute la requête.

L’épinglage de version est important lors de la mise à niveau d’une application vers une nouvelle version. Considérons le contexte où la version V1 d’une application exécute une requête complexe qui prend beaucoup de temps à se terminer.

Si une mise à niveau se produit alors que cette requête est toujours en cours d’exécution, l’état de mise à niveau de l’application passe à COMPLETE et l’application est mise à niveau vers v2. L’état de la version précédente passe à FINALIZING jusqu’à ce que toutes les tâches de la version v1 soient terminées.

Consultez États de mise à niveau pour plus d’informations sur les états de mise à niveau d’une application.

Restrictions sur les schémas versionnés¶

• Snowpark Container Services n’est pas pris en charge dans les schémas versionnés.

• Les schémas versionnés ne sont disponibles que dans le contexte d’un objet d’application. Ils ne sont créés que dans le script d’installation. Chaque version d’une application possède son propre script d’installation et contient des schémas spécifiques à cette version.

• Un schéma versionné ne peut être utilisé que dans le script d’installation d’un paquet d’application. Ils ne peuvent être créés que dans le contexte d’un objet d’application.

• Les tâches ne sont pas prises en charge dans les schémas versionnés. Par exemple, les fournisseurs ne peuvent pas inclure de balise lors de la création ou de la modification d’un schéma versionné. Toutefois, les fournisseurs peuvent utiliser des balises à l’intérieur d’un schéma versionné, à condition de n’appliquer ces objets balises qu’à l’intérieur d’un schéma versionné dans la même application.

• Les balises et les politiques de masquage ne sont pas prises en charge dans les schémas versionnés.

• Les autorisations et les futures autorisations ne sont pas prises en charge dans les schémas versionnés.

• Les schémas versionnés ne peuvent pas être utilisés comme source ou destination d’une opération de clonage.

• L’abandon d’un schéma versionné n’est pas pris en charge. L’abandon d’un schéma versionné entraînerait l’abandon de toutes les versions des objets qu’il contient et aurait un impact sur les requêtes exécutées avec des versions plus anciennes ou des correctifs de l’application.

Mise en œuvre interne de schémas versionnés¶

En interne, les schémas versionnés contiennent des sous-schémas qui correspondent à chaque version de l’application.

Toutefois, ces sous-schémas ne sont pas directement accessibles au consommateur dans l’objet de l’application. Un consommateur ne verra dans le schéma versionné que les objets correspondant à la version de l’application qu’il a installée sur son compte.

Par exemple, si un consommateur utilise la commande SHOW OBJECTS pour voir les objets d’un schéma versionné, il ne verra que les objets de la version qu’il utilise actuellement.

Lors de l’écriture du script d’installation, les fournisseurs doivent recréer des objets dans un schéma versionné en utilisant CREATE OR REPLACE ou CREATE IF NOT EXISTS. C’est important parce qu’en interne, chaque version de l’application a ses propres objets dans le sous-schéma du schéma versionné.

Utilisation de schémas versionnés et non versionnés dans le script d’installation¶

Pour gérer l’état d’une application lors des mises à niveau, le Snowflake Native App Framework utilise des schémas versionnés. Un schéma versionné est similaire à un schéma de base de données classique, avec des fonctionnalités supplémentaires permettant de gérer plusieurs versions d’objets créées par différentes versions d’applications.

Les schémas versionnés ne sont disponibles que dans le contexte d’un objet d’application. Ils ne sont créés que dans le script d’installation. Chaque version d’une application possède son propre script d’installation et contient des schémas spécifiques à cette version.

Lors du développement d’une nouvelle version d’une application, les fournisseurs doivent tenir compte des modifications apportées aux objets que l’application crée à l’aide du script d’installation.

L’exemple suivant montre une situation courante où les schémas versionnés et normaux peuvent être utilisés dans un script d’installation pour créer des composants avec ou sans état :

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;

Créer un schéma versionné¶

Pour créer un schéma versionné avec le script d’installation, utilisez la commande CREATE OR ALTER VERSIONED SCHEMA comme indiqué dans l’exemple suivant :

CREATE OR ALTER VERSIONED SCHEMA version_schema;

Utiliser des schémas non versionnés pour les objets avec état¶

Les objets d’une application peuvent avoir besoin de conserver leur état d’une version à l’autre. Par exemple, les données de configuration ou les données collectées pendant l’exécution de l’application peuvent être à préserver.

Ces types d’objets doivent résider dans un schéma de base de données normal et ils doivent être créés pour persister lors de l’installation initiale et des mises à niveau.

L’exemple suivant montre comment créer un objet avec état dans le script d’installation :

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;

Dans cet exemple, le script d’installation définit une table de configuration qui persistera d’une version à l’autre de l’application. Si la version précédente de l’application ne disposait pas d’une colonne modified_on, le script d’installation tente d’abord de créer entièrement la table (dans le cas d’une installation initiale) ou de modifier la table existante en y ajoutant la colonne (dans le cas d’une mise à niveau).

Utiliser des schémas versionnés pour les objets sans état¶

Certains objets d’une application ne conservent pas leur état entre les différentes versions de l’application. Par exemple, le code qui définit la logique d’application, y compris les procédures stockées, les fonctions, etc., peut être entièrement recréé dans le script d’installation sans perdre les données ou l’état de l’utilisateur.

Snowflake recommande que ces objets soient contenus dans un schéma versionné.

L’exemple suivant montre comment créer une UDF dans un schéma versionné.

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 $$;

Épinglage de la version¶

Un schéma versionné contient des métadonnées sur les objets d’une Snowflake Native App qui sont associés à une version spécifique. L’épinglage de version est une fonction des schémas versionnés qui permet à une application de savoir quels tâches, requêtes, etc. sont associés à ces objets.

Lorsqu’un objet d’un schéma versionné exécute une requête, par exemple, cette requête est « épinglée » à la version de l’application qui exécute la requête.

L’épinglage de version est important lors de la mise à niveau d’une application vers une nouvelle version. Considérons le contexte où la version V1 d’une application exécute une requête complexe qui prend beaucoup de temps à se terminer. Si une mise à niveau intervient alors que cette requête est toujours en cours, l’application ne sera pas mise à niveau tant que la requête ne sera pas terminée.