Migrieren von Projektdefinitionsdateien von Version 1.x nach 2.0

So konvertieren Sie eine Projektdefinitionsdatei der Version 1.x in das Format der Version 2:

  1. Gehen Sie in das Verzeichnis Ihres Projekts, das die snowflake.yml-Datei der Version 1.x enthält.

  2. Geben Sie den Befehl snow helpers v1-to-v2 ein.

    • Wenn die Konvertierung der Datei der Version 1.x erfolgreich war, zeigt der Befehl eine Meldung ähnlich der folgenden an:

      cd <project-directory>
snow helpers v1-to-v2

      Project definition migrated to version 2.

    • Wenn Ihre Projektdefinitionsdatei bereits auf Version 2 aktualisiert wurde, zeigt der Befehl die folgende Meldung an:

      cd <project-directory>
snow helpers v1-to-v2

      Project definition is already at version 2.

  • Wenn Sie versuchen, eine Projektdatei zu konvertieren, die eine Datei snowflake.local.yml enthält, ohne die Option --[no]-migrate-local-overrides zu verwenden, erzeugt der Befehl einen Fehler ähnlich dem folgenden:

  • Wenn Sie versuchen, eine Projektdatei zu konvertieren, die Vorlagen enthält, ohne die Option --accept-templates zu verwenden, erzeugt der Befehl einen Fehler ähnlich dem folgenden:

    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.                                                      |
+--------------------------------------------------------------------------+

  • Wenn Sie eine Projektdefinitionsdatei konvertieren, die Vorlagen enthält, und die Option --accept-templates verwenden, konvertiert der Befehl die Datei und zeigt eine Warnmeldung ähnlich der folgenden an:

    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

Native App-Projekte konvertieren

Dieser Abschnitt zeigt ein Beispiel für die Konvertierung eines Snowflake Native App-Projekts von V1 nach V2, listet die Änderungen bei den Eigenschaften auf und gibt einige Tipps zur Unterstützung der Migration.

Snowflake Native App-Beispiel für Konvertierung

Beispiel für die Konvertierung eines Native Apps-Projekts

V1-Projektdatei

V2-Projektdatei

 
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

Änderungen an Native App-Projektdefinition von V1- zu V2-Eigenschaften

Änderungen an Native App-Projektdefinition von V1- zu V2-Eigenschaften

V1-Eigenschaft

V2-Eigenschaft

native_app.name

Keine Entsprechung. Verwenden Sie eine Variable zum Portieren, falls erforderlich.

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 (siehe Anmerkungen oben)

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 (siehe Anmerkungen oben)

native_app.package.role

<package entity>.meta.role

native_app.package.scripts

<package entity>.meta.post_deploy (siehe Anmerkungen oben)

native_app.package.warehouse

<package entity>.meta.warehouse

Tipps zur Migration

  • Bei der Migration von Paketskripten für Snowflake Native Apps wandelt der Befehl v1-to-v2 diese in package post-deploy hooks um und ersetzt {{package_name}} in der Paketskriptdatei durch den entsprechenden Ausdruck der Vorlage.

  • Bei der Migration bestehender Ausdrucksvorlagen werden die Variablen ctx.native_app, ctx.streamlit und ctx.snowpark nicht mehr akzeptiert. Der Befehl v1-to-v2 mit äquivalenten Vorlagenausdrücken, die stattdessen auf den spezifischen Namen der Entität verweisen. Zum Beispiel könnte ctx.native_app.package.name durch ctx.entities.pkg.identifier ersetzt werden, wenn das Paket in eine Entität namens pkg in der snowflake.yml-Datei migriert wurde.

Streamlit-Projekte konvertieren

Dieser Abschnitt zeigt ein Beispiel für die Konvertierung eines Streamlit-Projekts von V1 nach V2, listet die Änderungen bei den Eigenschaften auf und gibt einige Tipps, die bei der Migration helfen.

Beispiel einer Streamlit-Konvertierung

Beispiel für die Konvertierung eines Streamlit-Projekts

V1-Projektdatei

V2-Projektdatei

 
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

Änderungen an Streamlit-Projektdefinition von V1- zu V2-Eigenschaften

Änderungen an Streamlit-Projektdefinition von V1- zu V2-Eigenschaften

V1-Eigenschaft

V2-Eigenschaft

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 and <streamlit entity>.artifacts

streamlit.stage

<streamlit entity>.stage

streamlit.env_file

<streamlit entity>.artifacts

streamlit.pages_dir

<streamlit entity>.pages_dir and <streamlit entity>.artifacts

streamlit.additional_source_files

<streamlit entity>.artifacts

Tipps für die Streamlit-Migration

Keine.

Snowpark-Projekte konvertieren

Dieser Abschnitt zeigt ein Beispiel für die Konvertierung eines Snowpark-Projekts von V1 nach V2, listet die Änderungen bei den Eigenschaften auf und gibt einige Tipps, die bei der Migration helfen.

Beispiel für eine Snowpark-Konvertierung

Beispiel für eine Snowpark-Projektkonvertierung

V1-Projektdatei

V2-Projektdatei

 
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

Änderungen an Snowpark-Projektdefinition von V1- zu V2-Eigenschaften

Änderungen an Snowpark-Projektdefinition von V1- zu V2-Eigenschaften

V1-Eigenschaft

V2-Eigenschaft

snowpark.project_name

<function or procedure entity>.artifacts.dest für jede Funktion und/oder Prozedur, die aus dem Projekt migriert wird. Siehe obige Anmerkungen zur Snowpark-Migration. Jede Funktion oder Prozedur sollte ein Artefakt deklarieren mit dest definiert als der Wert snowpark.project_name und src definiert als der Wert snowpark.src. Es wird die Verwendung eines Mixins empfohlen.

snowpark.stage_name

<function or procedure entity>.stage für jede Funktion und/oder Prozedur, die aus dem Projekt migriert wurde.

snowpark.src

<function or procedure entity>.artifacts.src für jede Funktion und/oder Prozedur, die aus dem Projekt migriert wurde (siehe snowpark.project_name oben).

snowpark.functions (Liste)

<function entities> (oberste Ebene)

snowpark.procedures (Liste)

<procedure entities> (oberste Ebene)
Änmderungen an Snowpark-Funktions- und Prozedurdefinition von V1- zu V2-Eigenschaften

V1-Eigenschaft

V2-Eigenschaft

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 (nur für Prozedur)

Snowpark-Migrationstipps

  • Bei der Migration von Snowpark-Projekten wird jede Funktion (aus dem Array snowpark.functions) oder Prozedur (aus dem Array snowpark.procedures) einer Entität der obersten Ebene zugeordnet.

  • Alle Snowpark Projekteigenschaften auf oberster Ebene (z.B. src) sind jetzt für jede Funktion und Prozedur definiert. Um Doppelarbeit zu vermeiden, empfiehlt Snowflake, ein mixin zu deklarieren und es in jede der migrierten Funktionen und Prozeduren einzubinden.