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 chamadaREFrepresenta essas referências. Um tipo de dadosREFé um contêiner para um identificador de objeto. Os valoresREFsã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 chamadaREFrepresenta essas referências. Um tipo de dadosREFé um contêiner para um identificador de objeto. Os valoresREFsã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¶
SSC-EWI-0001: Token não reconhecido na linha do código-fonte.
SSC-EWI-0073: Revisão de equivalência funcional pendente.
SSC-FDM-0001: As exibições que selecionam todas as colunas de uma única tabela não são obrigatórias no Snowflake.