Transformar traducciones de SQL con archivos YAML de configuración

En este documento se explica cómo usar archivos YAML de configuración para transformar código SQL al migrarlo a BigQuery. Incluye directrices para crear tus propios archivos YAML de configuración y proporciona ejemplos de varias transformaciones de traducción compatibles con esta función.

Cuando usas el traductor interactivo de SQL de BigQuery, la API BigQuery Migration o la traducción de SQL por lotes, puedes proporcionar archivos YAML de configuración para modificar la traducción de una consulta de SQL. El uso de archivos YAML de configuración permite personalizar aún más la traducción de las consultas SQL de tu base de datos de origen.

Puedes especificar un archivo YAML de configuración para usarlo en una traducción de SQL de las siguientes formas:

• Si usas el traductor interactivo de SQL, especifica la ruta del archivo de configuración o el ID del trabajo de traducción por lotes en los ajustes de traducción.
• Si usas la API Migration de BigQuery, coloca el archivo YAML de configuración en el mismo segmento de Cloud Storage que los archivos SQL de entrada.
• Si vas a realizar una traducción SQL por lotes, coloca el archivo YAML de configuración en el mismo segmento de Cloud Storage que los archivos SQL de entrada.
• Si usas el cliente de Python de traducción por lotes, coloca el archivo YAML de configuración en la carpeta de entrada de traducción local.

El traductor interactivo de SQL, la API de migración de BigQuery, el traductor por lotes de SQL y el cliente de Python de traducción por lotes admiten el uso de varios archivos YAML de configuración en un mismo trabajo de traducción. Consulta Aplicar varias configuraciones YAML para obtener más información.

Requisitos de los archivos YAML de configuración

Antes de crear un archivo YAML de configuración, consulta la siguiente información para asegurarte de que el archivo YAML es compatible con el servicio de migración de BigQuery:

• Debe subir los archivos YAML de configuración al directorio raíz del segmento de Cloud Storage que contiene los archivos de entrada de traducción de SQL. Para obtener información sobre cómo crear segmentos y subir archivos a Cloud Storage, consulta Crear segmentos y Subir objetos desde un sistema de archivos.
• El tamaño de un archivo YAML de configuración no debe superar 1 MB.
• El tamaño total de todos los archivos YAML de configuración utilizados en un mismo trabajo de traducción de SQL no debe superar los 4 MB.
• Si usas la sintaxis regex para la coincidencia de nombres, utiliza RE2/J.
• Todos los nombres de archivo YAML de configuración deben incluir la extensión .config.yaml, por ejemplo, change-case.config.yaml.
  • config.yaml no es un nombre válido para el archivo de configuración.

Directrices para crear un archivo YAML de configuración

En esta sección se ofrecen algunas directrices generales para crear un archivo YAML de configuración:

Header

Cada archivo de configuración debe contener un encabezado que especifique el tipo de configuración. El tipo object_rewriter se usa para especificar traducciones de SQL en un archivo YAML de configuración. En el siguiente ejemplo se usa el tipo object_rewriter para transformar el formato de un nombre:

type: object_rewriter
global:
  case:
    all: UPPERCASE

Selección de entidades

Para realizar transformaciones específicas de una entidad, especifícala en el archivo de configuración. Todas las propiedades match son opcionales. Solo debes usar las propiedades match que necesites para una transformación. El siguiente archivo YAML de configuración expone las propiedades que se deben coincidir para seleccionar entidades específicas:

match:
  database: <literal_name>
  schema: <literal_name>
  relation: <literal_name>
  attribute: <literal_name>
  databaseRegex: <regex>
  schemaRegex: <regex>
  relationRegex: <regex>
  attributeRegex: <regex>

Descripción de cada propiedad match:

• database o db: el componente project_id.
• schema: el componente del conjunto de datos.
• relation: el componente de tabla.
• attribute: el componente de columna. Solo es válido para la selección de atributos
• databaseRegex o dbRegex: coincide con una propiedad database con una expresión regular (Vista previa).
• schemaRegex: asocia las propiedades de schema con expresiones regulares (Vista previa).
• relationRegex: coincide con las propiedades relation con expresiones regulares (Vista previa).
• attributeRegex: coincide con las propiedades de attribute con expresiones regulares. Solo es válido para la selección de atributos (Vista previa).

Por ejemplo, el siguiente archivo YAML de configuración especifica las match propiedades para seleccionar la tabla testdb.acme.employee en una transformación de tabla temporal.

type: object_rewriter
relation:
-
  match:
    database: testdb
    schema: acme
    relation: employee
  temporary: true

Puede usar las propiedades databaseRegex, schemaRegex, relationRegex y attributeRegex para especificar expresiones regulares y seleccionar un subconjunto de entidades. En el siguiente ejemplo, se cambian todas las relaciones del esquema tmp_schema de testdb a temporales, siempre que su nombre empiece por tmp_:

type: object_rewriter
relation:
-
  match:
    schema: tmp_schema
    relationRegex: "tmp_.*"
  temporary: true

Tanto las propiedades literales como las regex se comparan sin distinguir entre mayúsculas y minúsculas. Puedes aplicar la distinción entre mayúsculas y minúsculas usando un regex con la marca i inhabilitada, como se muestra en el siguiente ejemplo:

match:
  relationRegex: "(?-i:<actual_regex>)"

También puedes especificar entidades completas mediante una sintaxis de cadena corta equivalente. La sintaxis de cadena corta espera exactamente 3 (para la selección de relaciones) o 4 (para la selección de atributos) segmentos de nombre delimitados con puntos, como en el ejemplo testdb.acme.employee. Los segmentos se interpretan internamente como si se hubieran enviado como database, schema, relation y attribute, respectivamente. Esto significa que los nombres se comparan literalmente, por lo que no se permiten expresiones regulares en la sintaxis abreviada. En el siguiente ejemplo se muestra el uso de la sintaxis de cadena corta para especificar una entidad completa en un archivo YAML de configuración:

type: object_rewriter
relation:
-
  match : "testdb.acme.employee"
  temporary: true

Si el nombre de una tabla contiene un punto, no puedes especificar el nombre con una sintaxis abreviada. En este caso, debe usar una coincidencia de objeto. En el siguiente ejemplo se cambia la tabla testdb.acme.stg.employee a temporal:

type: object_rewriter
relation:
-
  match:
    database: testdb
    schema: acme
    relation: stg.employee
  temporary: true

El archivo YAML de configuración acepta key como alias de match.

Base de datos predeterminada

Algunos dialectos de SQL de entrada, como Teradata, no admiten database-name en el nombre cualificado. En este caso, la forma más sencilla de asociar entidades es omitir la propiedad database en match.

Sin embargo, puede definir la propiedad default_database de BigQuery Migration Service y usar esa base de datos predeterminada en match.

Tipos de atributos de destino admitidos

Puede usar el archivo YAML de configuración para realizar transformaciones de tipo de atributo, en las que transforma el tipo de datos de una columna del tipo de origen al tipo de destino. El archivo YAML de configuración admite los siguientes tipos de destino:

• BOOLEAN
• TINYINT
• SMALLINT
• INTEGER
• BIGINT
• FLOAT
• DOUBLE
• NUMERIC (admite precisión y escala opcionales, como NUMERIC(18, 2))
• TIME
• TIMETZ
• DATE
• DATETIME
• TIMESTAMP
• TIMESTAMPTZ
• CHAR (Admite precisión opcional, como CHAR(42))
• VARCHAR (Admite precisión opcional, como VARCHAR(42))

Ejemplos de YAML de configuración

En esta sección se proporcionan ejemplos para crear varios archivos YAML de configuración que se pueden usar con tus traducciones de SQL. En cada ejemplo se describe la sintaxis de YAML para transformar la traducción de SQL de formas específicas, junto con una breve descripción. Cada ejemplo también proporciona el contenido de un archivo teradata-input.sql o hive-input.sql y un archivo bq-output.sql para que puedas comparar los efectos de un archivo YAML de configuración en una traducción de consulta de SQL de BigQuery.

En los siguientes ejemplos se usa Teradata o Hive como dialecto SQL de entrada y SQL de BigQuery como dialecto de salida. En los siguientes ejemplos también se usa testdb como base de datos predeterminada y testschema como ruta de búsqueda de esquemas.

Cambiar el uso de mayúsculas y minúsculas en el nombre de un objeto

La siguiente configuración de YAML cambia las mayúsculas o minúsculas de los nombres de los objetos:

type: object_rewriter
global:
  case:
    all: UPPERCASE
    database: LOWERCASE
    attribute: LOWERCASE

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table x(a int);
      select * from x;
    

      CREATE TABLE testdb.TESTSCHEMA.X
      (
        a INT64
      )
      ;
      SELECT
          X.a
        FROM
          testdb.TESTSCHEMA.X
      ;
    

Convertir una tabla en temporal

La siguiente configuración de YAML cambia una tabla normal a una tabla temporal:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    temporary: true

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int);
    

    CREATE TEMPORARY TABLE x
    (
      a INT64
    )
    ;
    

Crear una tabla efímera

La siguiente configuración YAML cambia una tabla normal a una tabla efímera con una caducidad de 60 segundos.

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    ephemeral:
      expireAfterSeconds: 60

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int);
    

    CREATE TABLE testdb.testschema.x
    (
      a INT64
    )
    OPTIONS(
      expiration_timestamp=timestamp_add(current_timestamp(), interval 60 SECOND)
    );
    

Definir la caducidad de la partición

La siguiente configuración YAML cambia la caducidad de una tabla particionada a 1 día:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    partitionLifetime:
      expireAfterSeconds: 86400

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int, b int) partition by (a);
    

    CREATE TABLE testdb.testschema.x
    (
      a INT64,
      b INT64
    )
    CLUSTER BY a
    OPTIONS(
      partition_expiration_days=1
    );
    

Cambiar la ubicación o el formato externos de una tabla

El siguiente archivo YAML de configuración cambia la ubicación y la formación externas de una tabla:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    external:
      locations: "gs://path/to/department/files"
      format: ORC

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int);
    

    CREATE EXTERNAL TABLE testdb.testschema.x
    (
      a INT64
    )
    OPTIONS(
      format='ORC',
      uris=[
        'gs://path/to/department/files'
      ]
    );
    

Definir o cambiar la descripción de una tabla

El siguiente archivo YAML de configuración define la descripción de una tabla:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    description:
      text: "Example description."

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int);
    

    CREATE TABLE testdb.testschema.x
    (
      a INT64
    )
    OPTIONS(
      description='Example description.'
    );
    

Definir o cambiar el particionado de una tabla

La siguiente configuración de YAML cambia el esquema de partición de una tabla:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    partition:
      simple:
        add: [a]
  -
    match: "testdb.testschema.y"
    partition:
      simple:
        remove: [a]

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a date, b int);
    create table y(a date, b int) partition by (a);
    

    CREATE TABLE testdb.testschema.x
    (
      a DATE,
      b INT64
    )
    PARTITION BY a;
    CREATE TABLE testdb.testschema.y
    (
      a DATE,
      b INT64
    )
    ;
    

Configurar o cambiar la agrupación en clústeres de tablas

El siguiente archivo YAML de configuración cambia el esquema de clustering de una tabla:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    clustering:
      add: [a]
  -
    match: "testdb.testschema.y"
    clustering:
      remove: [b]

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int, b int);
    create table y(a int, b int) clustered by (b) into 16 buckets;
    

    CREATE TABLE testdb.testschema.x
    (
      a INT64,
      b INT64
    )
    CLUSTER BY a;
    CREATE TABLE testdb.testschema.y
    (
      a INT64,
      b INT64
    )
    ;
    

Cambiar el tipo de un atributo de columna

La siguiente configuración YAML cambia el tipo de datos de un atributo de una columna:

type: object_rewriter
attribute:
  -
    match:
      database: testdb
      schema: testschema
      attributeRegex: "a+"
    type:
      target: NUMERIC(10,2)

Puede transformar el tipo de datos de origen en cualquiera de los tipos de atributos de destino admitidos.

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    create table x(a int, b int, aa int);
    

    CREATE TABLE testdb.testschema.x
    (
      a NUMERIC(31, 2),
      b INT64,
      aa NUMERIC(31, 2)
    )
    ;
    

Añadir una conexión a un lago de datos externo

El siguiente archivo YAML de configuración marca la tabla de origen como una tabla externa que apunta a los datos almacenados en un lago de datos externo, especificado por una conexión de lago de datos.

type: object_rewriter
relation:
-
  key: "testdb.acme.employee"
  external:
    connection_id: "connection_test"

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

    CREATE TABLE x
    (
      a VARCHAR(150),
      b INT
    );
    

    CREATE EXTERNAL TABLE x
    (
      a STRING,
      b INT64
    )
    WITH CONNECTION `connection_test`
    OPTIONS(
    );
    

Cambiar la codificación de caracteres de un archivo de entrada

De forma predeterminada, BigQuery Migration Service intenta detectar automáticamente la codificación de caracteres de los archivos de entrada. En los casos en los que el servicio de migración de BigQuery pueda identificar erróneamente la codificación de un archivo, puede usar un archivo YAML de configuración para especificar la codificación de caracteres de forma explícita.

El siguiente archivo YAML de configuración especifica la codificación de caracteres explícita del archivo de entrada como ISO-8859-1.

type: experimental_input_formats
formats:
- source:
    pathGlob: "*.sql"
  contents:
    raw:
      charset: iso-8859-1

Conversión de tipo global

La siguiente configuración YAML cambia un tipo de datos por otro en todas las secuencias de comandos y especifica un tipo de datos de origen que se debe evitar en la secuencia de comandos transpilada. Esta opción es diferente de la configuración Cambiar el tipo de un atributo de columna, en la que solo se cambia el tipo de datos de un atributo.

BigQuery admite las siguientes conversiones de tipos de datos:

• De DATETIME a TIMESTAMP
• TIMESTAMP a DATETIME (acepta la zona horaria opcional)
• TIMESTAMP WITH TIME ZONE a DATETIME (acepta la zona horaria opcional)
• De CHAR a VARCHAR

En el siguiente ejemplo, el archivo YAML de configuración convierte un tipo de datos TIMESTAMP en DATETIME.

type: experimental_object_rewriter
global:
  typeConvert:
    timestamp: DATETIME

En dialectos como Teradata, las funciones relacionadas con la fecha y la hora, como current_date, current_time o current_timestamp, devuelven marcas de tiempo basadas en la zona horaria configurada, ya sea local o de la sesión. Por otro lado, BigQuery siempre devuelve marcas de tiempo en UTC. Para que el comportamiento de los dos dialectos sea coherente, es necesario configurar la zona horaria correctamente.

En el siguiente ejemplo, el archivo YAML de configuración convierte los tipos de datos TIMESTAMP y TIMESTAMP WITH TIME ZONE en DATETIME, y la zona horaria de destino se define como Europe/Paris.

type: experimental_object_rewriter
global:
  typeConvert:
    timestamp:
      target: DATETIME
      timezone: Europe/Paris
    timestamptz:
      target: DATETIME
      timezone: Europe/Paris

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table x(a timestamp);
      select a from x where a > current_timestamp(0);
    

      CREATE TABLE x
      (
        a TIMESTAMP
      )
      ;
      SELECT
          x.a
        FROM
          test.x
        WHERE x.a > datetime_trunc(current_datetime('Europe/Paris'), SECOND)
      ;
    

Seleccionar modificación del extracto

La siguiente configuración de YAML cambia las cláusulas de proyección de estrella, GROUP BY y ORDER BY, en las instrucciones SELECT.

starProjection admite las siguientes configuraciones:

• ALLOW
• PRESERVE (predeterminado)
• EXPAND

groupBy y orderBy admiten las siguientes configuraciones:

• EXPRESSION
• ALIAS
• INDEX

En el ejemplo siguiente, el archivo YAML de configuración configura la proyección de estrellas en EXPAND.

type: experimental_statement_rewriter
select:
  starProjection: EXPAND

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table x(a int, b TIMESTAMP);
      select * from x;
    

      CREATE TABLE x
      (
        a INT64,
        b DATETIME
      )
      ;
      SELECT
          x.a
          x.b
        FROM
          x
      ;
    

Especificación de UDF

El siguiente archivo YAML de configuración especifica la firma de las funciones definidas por el usuario (UDFs) que se utilizan en las secuencias de comandos de origen. Al igual que los archivos ZIP de metadatos, las definiciones de UDF pueden ayudar a producir una traducción más precisa de las secuencias de comandos de entrada.

type: metadata
udfs:
  - "date parse_short_date(dt int)"

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table x(dt int);
      select parse_short_date(dt) + 1 from x;
    

      CREATE TABLE x
      (
        dt INT64
      )
      ;
      SELECT
          date_add(parse_short_date(x.dt), interval 1 DAY)
        FROM
          x
      ;
    

Definir la rigidez de la precisión decimal

De forma predeterminada, BigQuery Migration Service aumenta la precisión numérica a la más alta disponible para una escala determinada. El siguiente archivo YAML de configuración anula este comportamiento configurando la precisión estricta para conservar la precisión decimal de la instrucción de origen.

type: experimental_statement_rewriter
common:
  decimalPrecision: STRICT

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table x(a decimal(3,0));
    

      CREATE TABLE x
      (
        a NUMERIC(3)
      )
      ;
    

Asignación de nombres de salida

Puedes usar YAML de configuración para asignar nombres de objetos SQL. Puedes cambiar diferentes partes del nombre en función del objeto que se esté asignando.

Asignación de nombres estática

Usa la asignación de nombres estáticos para asignar el nombre de una entidad. Si solo quieres cambiar partes específicas del nombre y mantener el resto, incluye solo las partes que quieras modificar.

La siguiente configuración YAML cambia el nombre de la tabla de my_db.my_schema.my_table a my_new_db.my_schema.my_new_table.

type: experimental_object_rewriter
relation:
-
  match: "my_db.my_schema.my_table"
  outputName:
    database: "my_new_db"
    relation: "my_new_table"

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table my_db.my_schema.my_table(a int);
    

      CREATE TABLE my_new_db.my_schema.my_new_table
      (
        a INT64
      )
    

Puedes usar la asignación de nombres estáticos para actualizar la región que usan los nombres en las funciones públicas definidas por el usuario.

En el siguiente ejemplo se cambian los nombres de la función definida por el usuario bqutil.fn para que use la región europe_west2 en lugar de la multirregión us predeterminada:

type: experimental_object_rewriter
function:
-
  match:
    database: bqutil
    schema: fn
  outputName:
    database: bqutil
    schema: fn_europe_west2

Asignación de nombres dinámica

Usa la asignación de nombres dinámica para cambiar varios objetos al mismo tiempo y crear nombres nuevos basados en los objetos asignados.

La siguiente configuración YAML cambia el nombre de todas las tablas añadiendo el prefijo stg_ a las que pertenecen al esquema staging y, a continuación, mueve esas tablas al esquema production.

type: experimental_object_rewriter
relation:
-
  match:
    schema: staging
  outputName:
    schema: production
    relation: "stg_${relation}"

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table staging.my_table(a int);
    

      CREATE TABLE production.stg_my_table
      (
        a INT64
      )
      ;
    

Especificar la ruta de búsqueda predeterminada de la base de datos y del esquema

El siguiente archivo YAML de configuración especifica una base de datos predeterminada y una ruta de búsqueda de esquemas.

type: environment
session:
  defaultDatabase: myproject
  schemaSearchPath: [myschema1, myschema2]

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      SELECT * FROM database.table
      SELECT * FROM table1
    

      SELECT * FROM myproject.database.table.
      SELECT * FROM myproject.myschema1.table1
    

Reescritura del nombre de salida global

La siguiente configuración de YAML cambia los nombres de salida de todos los objetos (base de datos, esquema, relación y atributos) de la secuencia de comandos según las reglas configuradas.

type: experimental_object_rewriter
global:
  outputName:
    regex:
      - match: '\s'
        replaceWith: '_'
      - match: '>='
        replaceWith: 'gte'
      - match: '^[^a-zA-Z_].*'
        replaceWith: '_$0'

Una traducción de SQL con este archivo YAML de configuración podría tener el siguiente aspecto:

      create table "test special chars >= 12"("42eid" int, "custom column" varchar(10));
    

      CREATE TABLE test_special_chars_employees_gte_12
      (
        _42eid INT64,
        custom_column STRING
      )
      ;
    

Optimizar y mejorar el rendimiento de SQL traducido

Se pueden aplicar transformaciones opcionales al SQL traducido para introducir cambios que puedan mejorar la consulta en términos de rendimiento o coste. Estas optimizaciones dependen estrictamente de las mayúsculas y minúsculas, y deben evaluarse en comparación con la salida SQL sin modificar para determinar su efecto real en el rendimiento.

El siguiente archivo YAML de configuración habilita las transformaciones opcionales. La configuración acepta una lista de optimizaciones y, en el caso de las optimizaciones que aceptan parámetros, una sección con valores de parámetros opcionales.

type: optimizer
transformations:
  - name: PRECOMPUTE_INDEPENDENT_SUBSELECTS
  - name: REWRITE_CTE_TO_TEMP_TABLE
    parameters:
      threshold: 1

Crear un archivo YAML de configuración basado en Gemini

Para generar resultados de IA, el directorio de origen que contiene la entrada de traducción de SQL debe incluir un archivo YAML de configuración.

Requisitos

El archivo YAML de configuración de las salidas de la IA debe tener el sufijo .ai_config.yaml. Por ejemplo, rules_1.ai_config.yaml.

Campos admitidos

Puede usar los siguientes campos para configurar el resultado de la traducción con IA:

• suggestion_type (opcional): especifica el tipo de sugerencia de IA que se va a generar. Se admiten los siguientes tipos de sugerencias:
  • QUERY_CUSTOMIZATION (opción predeterminada): genera sugerencias de IA para el código SQL basadas en las reglas de traducción especificadas en el archivo YAML de configuración.
  • TRANSLATION_EXPLANATION: genera texto que incluye un resumen de la consulta de GoogleSQL traducida y las diferencias e incoherencias entre la consulta de SQL de origen y la consulta de GoogleSQL traducida.
• rewrite_target (opcional): especifica SOURCE_SQL si quieres aplicar la regla de traducción al SQL de entrada o TARGET_SQL (valor predeterminado) si quieres aplicar la regla de traducción al SQL de salida.
• instruction (opcional): describe en lenguaje natural el cambio que quieres hacer en el SQL de destino. La traducción de SQL mejorada con Gemini evalúa la solicitud y hace el cambio especificado.
• examples (opcional): Proporciona ejemplos de SQL de cómo quieres que se modifique el patrón de SQL.

Puedes añadir más translation_rules y examples según sea necesario.

Ejemplos

En los siguientes ejemplos se crean archivos YAML de configuración basados en Gemini que puedes usar con tus traducciones de SQL.

Quita la función superior de la consulta de salida de traducción predeterminada

translation_rules:
- instruction: "Remove upper() function"
  examples:
  - input: "upper(X)"
    output: "X"

Crear varias reglas de traducción para personalizar el resultado de la traducción

translation_rules:
- instruction: "Remove upper() function"
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL
  examples:
  - input: "upper(X)"
    output: "X"
- instruction: "Insert a comment at the head that explains each statement in detail.
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL

Eliminar comentarios de SQL de la consulta de entrada de traducción

translation_rules:
- instruction: "Remove all the sql comments in the input sql query."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: SOURCE_SQL

Generar explicaciones de traducciones con la petición predeterminada de LLM

En este ejemplo se usan las peticiones predeterminadas de LLM proporcionadas por el servicio de traducción para generar explicaciones de texto:

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"

Genera explicaciones de traducciones usando tus propias peticiones en lenguaje natural

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
  instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."

Varios tipos de sugerencias en un único archivo YAML de configuración

translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
  instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."
- instruction: "Remove upper() function"
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: TARGET_SQL
  examples:
  - input: "upper(X)"
    output: "X"
- instruction: "Remove all the sql comments in the input sql query."
  suggestion_type: QUERY_CUSTOMIZATION
  rewrite_target: SOURCE_SQL

Aplicar varias configuraciones YAML

Cuando especifiques un archivo YAML de configuración en una traducción de SQL interactiva o por lotes, puedes seleccionar varios archivos YAML de configuración en un solo trabajo de traducción para reflejar varias transformaciones. Si hay varias configuraciones que entran en conflicto, una transformación puede anular otra. Te recomendamos que uses diferentes tipos de ajustes de configuración en cada archivo para evitar transformaciones contradictorias en el mismo trabajo de traducción.

En el siguiente ejemplo se muestran dos archivos YAML de configuración independientes que se han proporcionado para un único trabajo de traducción de SQL. Uno de ellos se usa para cambiar el atributo de una columna y el otro, para definir la tabla como temporal:

change-type-example.config.yaml:

type: object_rewriter
attribute:
  -
    match: "testdb.testschema.x.a"
    type:
      target: NUMERIC(10,2)

make-temp-example.config.yaml:

type: object_rewriter
relation:
  -
    match: "testdb.testschema.x"
    temporary: true

Una traducción de SQL con estos dos archivos YAML de configuración podría tener el siguiente aspecto:

    create table x(a int);
    

    CREATE TEMPORARY TABLE x
    (
      a NUMERIC(31, 2)
    )
    ;