Migration des fichiers de définition de projet de la version 1.x vers la version 2.0¶
Pour convertir un fichier de définition de projet de version 1.x au format de version 2, procédez comme suit :
Accédez au répertoire de votre projet qui contient la version 1.x du fichier
snowflake.yml
.Entrez la commande
snow helpers v1-to-v2
.Si la conversion du fichier version 1.x réussit, la commande affiche un message similaire au suivant :
cd <project-directory> snow helpers v1-to-v2
Project definition migrated to version 2.
Si votre fichier de définition de projet est déjà mis à jour vers la version 2, la commande affiche le message suivant :
cd <project-directory> snow helpers v1-to-v2
Project definition is already at version 2.
Si vous essayez de convertir un fichier de projet qui contient un fichier
snowflake.local.yml
, sans utiliser l’option--[no]-migrate-local-overrides
, la commande génère une erreur similaire à la suivante :
Si vous essayez de convertir un fichier de projet contenant des modèles, sans utiliser l’option
--accept-templates
, la commande génère une erreur similaire à la suivante :cd <project-directory> snow helpers v1-to-v2+- Error-------------------------------------------------------------------+ | snowflake.local.yml file detected, please specify | | --migrate-local-overrides to include or --no-migrate-local-overrides to | | exclude its values. | +--------------------------------------------------------------------------+Si vous convertissez un fichier de définition de projet contenant des modèles et utilisez l’option
--accept-templates
, la commande convertit le fichier et affiche un message d’avertissement similaire au suivant :cd <project-directory> snow helpers v1-to-v2WARNING snowflake.cli._plugins.workspace.commands:commands.py:60 Your V1 definition contains templates. We cannot guarantee the correctness of the migration. Project definition migrated to version 2
Convertir des projets Native App¶
Cette section montre un exemple de conversion V1 en V2 d’un projet Snowflake Native App, répertorie les modifications apportées aux noms de propriétés et propose quelques conseils pour faciliter la migration.
Exemple de conversion de Snowflake Native App¶
Fichier de projet V1 |
Fichier de projet V2 |
---|---|
definition_version: 1
native_app:
name: myapp
source_stage: app_src.stage
artifacts:
- src: app/*
dest: ./
processors:
- native app setup
- name: templates
properties:
foo: bar
package:
role: pkg_role
distribution: external
application:
name: myapp_app
warehouse: app_wh
|
definition_version: 2
entities:
pkg:
type: application package
meta:
role: pkg_role
identifier: <% fn.concat_ids('myapp', '_pkg_', fn.sanitize_id(fn.get_username('unknown_user')) | lower) %>
manifest: app/manifest.yml
artifacts:
- src: app/*
dest: ./
processors:
- name: native app setup
- name: templates
properties:
foo: bar
stage: app_src.stage
app:
meta:
warehouse: app_wh
identifier: myapp_app
type: application
from:
target: pkg
|
Modifications des propriétés de la définition du projet Native App de la V1 à la V2¶
Propriété V1 |
Propriété V2 |
---|---|
|
Pas d’équivalent. Utilisez une variable de modèle pour le portage, si nécessaire. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conseils de migration¶
Lors de la migration des scripts du paquet Snowflake Native App, la commande
v1-to-v2
les convertit en scriptspackage post-deploy
et remplace{{package_name}}
dans le fichier de script du paquet avec l’expression de modèle équivalente.Lors de la migration d’expressions de modèle existantes, les variables
ctx.native_app
,ctx.streamlit
, etctx.snowpark
ne sont plus acceptées. La commandev1-to-v2
avec des expressions de modèle équivalentes qui font référence au nom de l’entité spécifique à la place. Par exemple,ctx.native_app.package.name
pourrait être remplacé parctx.entities.pkg.identifier
si le paquet a été migré vers une entité nomméepkg
dans le fichiersnowflake.yml
.
Convertir des projets Streamlit¶
Cette section montre un exemple de conversion V1 vers V2 d’un projet Streamlit, répertorie les modifications apportées aux noms de propriétés et propose quelques conseils pour faciliter la migration.
Exemple de conversion Streamlit¶
Fichier de projet V1 |
Fichier de projet V2 |
---|---|
definition_version: 1
streamlit:
name: test_streamlit
stage: streamlit
query_warehouse: test_warehouse
main_file: "streamlit_app.py"
title: "My Fancy Streamlit"
|
definition_version: 2
entities:
test_streamlit:
identifier:
name: test_streamlit
type: streamlit
title: My Fancy Streamlit
query_warehouse: test_warehouse
main_file: streamlit_app.py
pages_dir: None
stage: streamlit
artifacts:
- streamlit_app.py
|
Modifications des propriétés de la définition du projet Streamlit de V1 à V2¶
Propriété V1 |
Propriété V2 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conseils de migration Streamlit¶
Aucun.
Convertir des projets Snowpark¶
Cette section montre un exemple de conversion V1 vers V2 d’un projet Snowpark, répertorie les modifications apportées aux noms de propriétés et propose quelques conseils pour faciliter la migration.
Exemple de conversion Snowpark¶
Fichier de projet V1 |
Fichier de projet V2 |
---|---|
definition_version: 1
snowpark:
project_name: "my_snowpark_project"
stage_name: "dev_deployment"
src: "app/"
functions:
- name: func1
handler: "app.func1_handler"
signature:
- name: "a"
type: "string"
default: "default value"
- name: "b"
type: "variant"
returns: string
runtime: 3.10
procedures:
- name: procedureName
handler: "hello"
signature:
- name: "name"
type: "string"
returns: string
|
definition_version: 2
entities:
procedureName:
imports: []
external_access_integrations: []
secrets: {}
meta:
use_mixins:
- snowpark_shared
identifier:
name: procedureName
handler: hello
returns: string
signature:
- name: name
type: string
stage: dev_deployment
artifacts:
- src: app
dest: my_snowpark_project
type: procedure
execute_as_caller: false
func1:
imports: []
external_access_integrations: []
secrets: {}
meta:
use_mixins:
- snowpark_shared
identifier:
name: func1
handler: app.func1_handler
returns: string
signature:
- name: a
type: string
default: default value
- name: b
type: variant
runtime: '3.10'
stage: dev_deployment
artifacts:
- src: app
dest: my_snowpark_project
type: function
mixins:
snowpark_shared:
stage: dev_deployment
artifacts:
- src: app/
dest: my_snowpark_project
|
Modifications des propriétés de la définition du projet Snowpark V1 à V2¶
Propriété V1 |
Propriété V2 |
---|---|
|
|
|
|
|
|
|
|
|
|
Propriété V1 |
Propriété V2 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conseils pour la migration Snowpark¶
Lors de la migration de projets Snowpark, chaque fonction (depuis le tableau
snowpark.functions
) ou procédure (depuis le tableausnowpark.procedures
) correspond à une entité de niveau supérieur.Toutes les propriétés de projet Snowpark de niveau supérieur (par exemple :
src
) sont désormais définies pour chaque fonction et procédure. Pour réduire les doublons, Snowflake vous recommande de déclarer unmixin
et de l’inclure dans chacune des entités de fonction et de procédure migrées.