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:
Gehen Sie in das Verzeichnis Ihres Projekts, das die
snowflake.yml-Datei der Version 1.x enthält.Geben Sie den Befehl
snow helpers v1-to-v2ein.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.ymlenthält, ohne die Option--[no]-migrate-local-overrideszu verwenden, erzeugt der Befehl einen Fehler ähnlich dem folgenden:
Wenn Sie versuchen, eine Projektdatei zu konvertieren, die Vorlagen enthält, ohne die Option
--accept-templateszu 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-templatesverwenden, konvertiert der Befehl die Datei und zeigt eine Warnmeldung ähnlich der folgenden an: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
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¶
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¶
V1-Eigenschaft  | 
V2-Eigenschaft  | 
|---|---|
  | 
Keine Entsprechung. Verwenden Sie eine Variable zum Portieren, falls erforderlich.  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
Tipps zur Migration¶
Bei der Migration von Paketskripten für Snowflake Native Apps wandelt der Befehl
v1-to-v2diese inpackage post-deployhooks 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.streamlitundctx.snowparknicht mehr akzeptiert. Der Befehlv1-to-v2mit äquivalenten Vorlagenausdrücken, die stattdessen auf den spezifischen Namen der Entität verweisen. Zum Beispiel könntectx.native_app.package.namedurchctx.entities.pkg.identifierersetzt werden, wenn das Paket in eine Entität namenspkgin dersnowflake.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¶
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¶
V1-Eigenschaft  | 
V2-Eigenschaft  | 
|---|---|
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
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¶
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¶
V1-Eigenschaft  | 
V2-Eigenschaft  | 
|---|---|
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
V1-Eigenschaft  | 
V2-Eigenschaft  | 
|---|---|
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
  | 
Snowpark-Migrationstipps¶
Bei der Migration von Snowpark-Projekten wird jede Funktion (aus dem Array
snowpark.functions) oder Prozedur (aus dem Arraysnowpark.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, einmixinzu deklarieren und es in jede der migrierten Funktionen und Prozeduren einzubinden.