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 :

  1. Accédez au répertoire de votre projet qui contient la version 1.x du fichier snowflake.yml.

  2. 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-v2

    WARNING  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

Exemple de conversion de projet Native Apps

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

Modifications des propriétés de la définition du projet Native App de la V1 à la V2

Propriété V1

Propriété V2

native_app.name

Pas d’équivalent. Utilisez une variable de modèle pour le portage, si nécessaire.

native_app.deploy_root

<package entity>.deploy_root

native_app.generated_root

<package entity>.generated_root

native_app.bundle_root

<package entity>.bundle_root

native_app.source_stage

<package entity>.source_stage

native_app.scratch_stage

<package entity>.scratch_stage

native_app.artifacts

<package entity>.artifacts

native_app.application.debug

<application entity>.debug

native_app.application.name

<application entity>.identifier

native_app.application.post_deploy

<application entity>.meta.post_deploy (voir les notes ci-dessus)

native_app.application.role

<application entity>.meta.role

native_app.application.warehouse

<application entity>.meta.warehouse

native_app.package.distribution

<package entity>.distribution

native_app.package.name

<package entity>.identifier

native_app.package.post_deploy

<package entity>.meta.post_deploy (voir les notes ci-dessus)

native_app.package.role

<package entity>.meta.role

native_app.package.scripts

<package entity>.meta.post_deploy (voir les notes ci-dessus)

native_app.package.warehouse

<package entity>.meta.warehouse

Conseils de migration

  • Lors de la migration des scripts du paquet Snowflake Native App, la commande v1-to-v2 les convertit en scripts package 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, et ctx.snowpark ne sont plus acceptées. La commande v1-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é par ctx.entities.pkg.identifier si le paquet a été migré vers une entité nommée pkg dans le fichier snowflake.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

Exemple de conversion de projet 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

Modifications des propriétés de la définition du projet Streamlit de V1 à V2

Propriété V1

Propriété V2

streamlit.name

<streamlit entity>.identifier.name

streamlit.schema

<streamlit entity>.identifier.schema

streamlit.database

<streamlit entity>.identifier.database

streamlit.comment

<streamlit entity>.comment

streamlit.title

<streamlit entity>.title

streamlit.query_warehouse

<streamlit entity>.query_warehouse

streamlit.main_file

<streamlit entity>.main_file et <streamlit entity>.artifacts

streamlit.stage

<streamlit entity>.stage

streamlit.env_file

<streamlit entity>.artifacts

streamlit.pages_dir

<streamlit entity>.pages_dir et <streamlit entity>.artifacts

streamlit.additional_source_files

<streamlit entity>.artifacts

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

Exemple de conversion d’un projet 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

Modifications des propriétés de la définition du projet Snowpark V1 à V2

Propriété V1

Propriété V2

snowpark.project_name

<function or procedure entity>.artifacts.dest pour chaque fonction et/ou procédure migrée depuis le projet. Voir les notes ci-dessus concernant la migration vers Snowpark. Chaque fonction ou procédure doit déclarer un artefact avec dest défini comme la valeur snowpark.project_name et src défini comme la valeur snowpark.src. L’utilisation d’un mixin est recommandée.

snowpark.stage_name

<function or procedure entity>.stage pour chaque fonction et/ou procédure migrée depuis le projet.

snowpark.src

<function or procedure entity>.artifacts.src pour chaque fonction et/ou procédure migrée depuis le projet. (voir snowpark.project_name above)

snowpark.functions (liste)

<function entities> (niveau supérieur)

snowpark.procedures (liste)

<procedure entities> (niveau supérieur)
Modifications des propriétés V1 à V2 de la définition de la fonction et de la procédure Snowpark

Propriété V1

Propriété V2

name

identifier.name

schema

identifier.schema

database

identifier.database

handler

handler

returns

returns

signature

signature

runtime

runtime

external_access_integrations

external_access_integrations

secrets

secrets

imports

imports

execute_as_caller

execute_as_caller (uniquement pour les procédures)

Conseils pour la migration Snowpark

  • Lors de la migration de projets Snowpark, chaque fonction (depuis le tableau snowpark.functions) ou procédure (depuis le tableau snowpark.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 un mixin et de l’inclure dans chacune des entités de fonction et de procédure migrées.