SnowConvert AI - Oracle - Tipos definidos pelo usuário

Descrição

Os tipos de dados definidos pelo usuário usam os tipos de dados incorporados do Oracle e outros tipos de dados definidos pelo usuário como blocos de construção de tipos de objetos que modelam a estrutura e o comportamento dos dados nos aplicativos. As seções a seguir descrevem as várias categorias de tipos definidos pelo usuário. (Tipos de dados definidos pelo usuário da referência de linguagem Oracle SQL)

Aviso

O Snowflake não tem suporte para tipos definidos pelo usuário. Esta página deve ser um resumo dos recursos da Oracle. Para obter o status atual dos tipos definidos pelo usuário na ferramenta SnowConvert AIe, consulte a página Criação de instrução de tipo e suas subpáginas.

Tipos de objetos

Nota

O SnowConvert AI oferece tradução parcial para tipos de objeto. Para mais informações sobre isso, consulte a próxima seção: Definição do tipo de objeto

Tipos de dados de REF

Perigo

Os tipos de dados Ref não são reconhecidos pelo SnowConvert AI, sendo exibidos como «Funções Definidas pelo Usuário» não reconhecidas. Para mais informações sobre eles, leia a Subpágina de Tipos de dados REF.

Um identificador de objeto (representado pela palavra-chave OID) identifica de forma exclusiva um objeto e permite que você faça referência a ele a partir de outros objetos ou de tabelas relacionais. Uma categoria de tipo de dados chamada REF representa essas referências. Um tipo de dados REF é um contêiner para um identificador de objeto. Os valores REF são ponteiros para objetos. (Tipo de dados REF da referência de linguagem Oracle SQL)

Varrays

Aviso

O SnowConvert AI apenas reconhece esses elementos, mas não oferece nenhuma tradução para eles. Para mais informações sobre isso, consulte a próxima seção: [Definição do tipo de matriz](../../sql-translation-reference/create_type.md#array- definição de tipo)

Tabelas aninhadas

Aviso

O SnowConvert AI apenas reconhece esses elementos, mas não oferece nenhuma tradução para eles, pois não há soluções alternativas conhecidas para eles. Para mais informações sobre isso, consulte a próxima seção:[Definição do tipo de tabela aninhada](../../sql-translation -reference/create_type.md#nested-table-type-definition)

Problemas conhecidos

1. DML usages for Object Types are not being transformed

No momento, apenas as definições do DDL que usam tipos definidos pelo usuário estão sendo transformadas em Variant. Isso significa que todas as inserções, atualizações ou exclusões que usam tipos definidos pelo usuário não estão sendo transformadas e precisam ser transformadas manualmente. Não há EWI para isso, mas há um item de trabalho para adicionar esse EWI correspondente.

2. Nested Table types are not being transformed

Não há solução alternativa para implementar tabelas aninhadas; por esse motivo, o SnowConvert AI oferece apenas o reconhecimento desses elementos.

3. Array types are not being transformed

Por enquanto, o SnowConvert AI reconhece apenas esses elementos. Existe uma solução alternativa conhecida e há um item de trabalho para implementá-la.

Tipos de dados de REF

Nota

Algumas partes do código de saída foram omitidas por motivos de clareza.

Descrição

Um identificador de objeto (representado pela palavra-chave OID) identifica exclusivamente um objeto e permite que você faça referência ao objeto a partir de outros objetos ou tabelas relacionais. Uma categoria de tipo de dados chamada REF representa essas referências. Um tipo de dados REF é um contêiner para um identificador de objeto. Os valores REF são ponteiros para objetos. (Tipo de dados REF da referência de linguagem Oracle SQL)

Os tipos de dados REF não são compatíveis com o Snowflake, e não há nenhuma solução atual para implementar um componente semelhante.

No momento, elas estão sendo reconhecidas como funções definidas pelo usuário e as cláusulas «DANGLING» não estão sendo reconhecidas. Por fim, a cláusula OID na visualização está sendo removida, pois não há solução alternativa para ela.

CREATE VIEW generic_view AS
SELECT REF(type) AS ref_col, MAKE_REF(type, identifier_column) AS make_ref_col
FROM generic_table;

SELECT v.ref_col, v.make_ref_col
FROM generic_view v
WHERE v.ref_col IS NOT DANGLING AND v.make_ref_col IS NOT DANGLING

Amostra de padrões da origem

Tipos e tabelas de referências

Considere os seguintes tipos, tabelas, inserções e visualizações. Elas serão usadas na próxima seção do padrão.

Oracle
CREATE TYPE email_typ_demo AS OBJECT
	( email_id INTEGER
	, email VARCHAR2(30)
	);

CREATE TYPE customer_typ_demo AS OBJECT
    ( customer_id        INTEGER
    , cust_first_name    VARCHAR2(20)
    , cust_last_name     VARCHAR2(20)
    , email_id			 INTEGER
    ) ;

CREATE TABLE email_table_demo OF email_typ_demo;
CREATE TABLE customer_table_demo OF customer_typ_demo;

INSERT INTO customer_table_demo VALUES
(customer_typ_demo(1, 'First Name 1', 'Last Name 1', 1));

INSERT INTO customer_table_demo VALUES
(customer_typ_demo(2, 'First Name 2', 'Last Name 2', 2));

INSERT INTO email_table_demo VALUES 
(email_typ_demo(1, 'abc@def.com'));

CREATE VIEW email_object_view OF email_typ_demo WITH OBJECT IDENTIFIER (email_id) AS
SELECT * FROM email_table_demo;

Seleciona e visualiza usando REFs

Oracle
CREATE VIEW email_object_view OF email_typ_demo WITH OBJECT IDENTIFIER (email_id) AS
SELECT * FROM email_table_demo;

CREATE VIEW customer_view AS
SELECT REF(ctb) AS customer_reference
     , MAKE_REF(email_object_view, ctb.email_id) AS email_ref
FROM customer_table_demo ctb;

SELECT c.customer_reference.cust_first_name, c.email_ref.email
FROM customer_view c;

SELECT c.customer_reference.cust_first_name, c.email_ref.email
FROM customer_view c
WHERE c.email_ref IS NOT DANGLING;
Resultado com pendências

CUSTOMER_REFERENCE.CUST_FIRST_NAME

EMAIL_REF.EMAIL

Nome 1

abc@def.com

Nome 2

Resultado sem pendências

CUSTOMER_REFERENCE.CUST_FIRST_NAME

EMAIL_REF.EMAIL

Nome 1

abc@def.com
Snowflake
CREATE OR REPLACE VIEW email_object_view
COMMENT = '{"origin":"sf_sc","name":"snowconvert","version":{"major":1, "minor":0},"attributes":{"component":"oracle"}}'
AS
--** SSC-FDM-0001 - VIEWS SELECTING ALL COLUMNS FROM A SINGLE TABLE ARE NOT REQUIRED IN SNOWFLAKE AND MAY IMPACT PERFORMANCE. **
SELECT * FROM
     email_table_demo;

CREATE OR REPLACE VIEW customer_view
COMMENT = '{"origin":"sf_sc","name":"snowconvert","version":{"major":1, "minor":0},"attributes":{"component":"oracle"}}'
AS
SELECT REF(ctb) !!!RESOLVE EWI!!! /*** SSC-EWI-0073 - PENDING FUNCTIONAL EQUIVALENCE REVIEW FOR 'REF' NODE ***/!!! AS customer_reference
     , MAKE_REF(email_object_view, ctb.email_id) !!!RESOLVE EWI!!! /*** SSC-EWI-0073 - PENDING FUNCTIONAL EQUIVALENCE REVIEW FOR 'MAKE_REF' NODE ***/!!! AS email_ref
FROM
     customer_table_demo ctb;

     SELECT c.customer_reference.cust_first_name, c.email_ref.email
     FROM
     customer_view c;

     SELECT c.customer_reference.cust_first_name, c.email_ref.email
FROM
     customer_view c
WHERE c.email_ref;
-- ** SSC-EWI-0001 - UNRECOGNIZED TOKEN ON LINE '14' COLUMN '19' OF THE SOURCE CODE STARTING AT 'IS'. EXPECTED 'STATEMENT' GRAMMAR. LAST MATCHING TOKEN WAS ';' ON LINE '10' COLUMN '21'. FAILED TOKEN WAS 'IS' ON LINE '14' COLUMN '19'. CODE '94'. **
--                   IS NOT DANGLING

Problemas conhecidos

1. REF e MAKE_REF não estão sendo reconhecidos

Em vez disso, elas estão sendo marcadas como funções definidas pelo usuário.

2. A cláusula DANGLING não está sendo reconhecida

DANGLING causa erros de análise ao executar SnowConvert.

EWIs relacionados

  1. SSC-EWI-0001: Token não reconhecido na linha do código-fonte.

  2. SSC-EWI-0073: Revisão de equivalência funcional pendente.

  3. SSC-FDM-0001: As exibições que selecionam todas as colunas de uma única tabela não são obrigatórias no Snowflake.