Detalhes da Conexão do Couchbase¶

Introdução¶

Versão do conector

Esta documentação é baseada na versão 21.0.8257 do conector.

Começando¶

Suporte à versão Couchbase

O Jitterbit Connector for Couchbase modela documentos Couchbase em um bucket como tabelas em um banco de dados relacional; conecte-se ao Couchbase Server versões 4.0 e superiores, Enterprise Edition ou Community Edition.

Estabelecendo uma Conexão¶

Conectando ao Couchbase¶

Para se conectar aos dados, defina o Server propriedade para o nome do host ou endereço IP do(s) servidor(es) Couchbase no qual você está se autenticando. Se o seu servidor Couchbase estiver configurado para usar SSL, você poderá ativá-lo usando uma URL https para Server (como 'https://couchbase.server'), ou definindo o UseSSL propriedade para True.

Couchbase Analytics¶

Por padrão, o conector se conecta ao serviço N1QL Query. Para se conectar ao serviço Couchbase Analytics, você também precisará definir o CouchbaseService propriedade para Analytics.

Nuvem Couchbase¶

Algumas configurações especiais são necessárias para se conectar ao Couchbase Cloud:

• Colocou o AuthScheme para Basic
• Colocou o Server opção para o domínio listado no console do Couchbase Cloud.
• Habilite o UseSSL opção.
• Colocou o ConnectionMode para Cloud
• Colocou o DNSServer opção para um servidor DNS. Na maioria dos casos, deve ser um serviço DNS público como 1.1.1.1 ou 8.8.8.8.
• Colocou o SSLServerCert opção para \* para confiar no certificado do servidor Couchbase. Você também pode fornecer o certificado usando essa opção ou seu armazenamento confiável se desejar que o conector o valide.

Autenticação com Couchbase¶

O conector oferece suporte a várias formas de autenticação, dependendo de como seu Couchbase Server está configurado. O Couchbase Cloud aceita apenas autenticação padrão, enquanto o Couchbase Server aceita todos os formulários.

Autenticação com Autenticação Padrão¶

Para autenticar com autenticação padrão, defina o seguinte:

• AuthScheme: Use o Basic opção.
• User: O usuário autenticando no Couchbase.
• Password: A senha do usuário autenticando no Couchbase.

Autenticação com Certificados de Cliente¶

O conector oferece suporte à autenticação com certificados de cliente quando o SSL está habilitado. Para usar a autenticação de certificado de cliente, defina as seguintes propriedades.

• AuthScheme: Obrigatório. Use o SSLCertificate opção.
• SSLClientCertType: Obrigatório. O tipo de certificado de cliente definido em SSLClientCert.
• SSLClientCert: Obrigatório. O certificado do cliente no formato fornecido por SSLClientCertType. Normalmente, o caminho para o arquivo de chave privada.
• SSLClientCertPassword: Opcional. A senha do certificado do cliente, se estiver criptografada.
• SSLClientCertSubject: Opcional. O assunto do certificado do cliente, por padrão, o primeiro certificado encontrado na loja. Isso é necessário se mais de um certificado estiver disponível no armazenamento de certificados.

Autenticação com um Arquivo de Credenciais¶

Você também pode autenticar usando um arquivo de credenciais contendo vários logins. Isso está incluído para uso herdado e não é recomendado ao se conectar a um Couchbase Server que suporte autenticação baseada em função.

• AuthScheme: Use o CredentialsFile opção.
• CredentialsFile; O caminho para o arquivo de credenciais. Consulte a documentação do Couchbase para obter mais informações sobre o formato deste arquivo.

Anotações Importantes¶

Procedimentos Armazenados¶

• Os recursos de procedimentos armazenados descritos nesta documentação não são suportados no momento.
• Como os procedimentos armazenados não são suportados atualmente, qualquer recurso dependente de procedimentos armazenados também não é suportado atualmente.

Arquivos de Configuração e Seus Caminhos¶

• Todas as referências para adicionar arquivos de configuração e seus caminhos referem-se a arquivos e locais no Harmony Agente onde o conector está instalado. Esses caminhos devem ser ajustados conforme apropriado, dependendo do agente e do sistema operacional. Se vários agentes forem usados em um grupo de agentes, arquivos idênticos serão necessários em cada agente.

Banco de Dados NoSQL¶

O Couchbase é um banco de dados de documentos sem esquema que fornece alto desempenho, disponibilidade e escalabilidade. Esses recursos não são necessariamente incompatíveis com uma linguagem de consultar compatível com padrões como o SQL-92.

O conector modela os objetos Couchbase sem esquema em tabelas relacionais e converte as consultas SQL em consultas N1QL ou SQL++ (Analytics) para obter os dados solicitados. Nesta seção, mostraremos vários esquemas que o conector oferece para preencher a lacuna com o SQL relacional e um banco de dados de documentos.

Descoberta automática de esquema

Quando o conector se conecta pela primeira vez ao Couchbase, ele abre cada depósito e verifica um número configurável de linhas desse depósito. Ele usa essas linhas para determinar as colunas nesse bloco e seus tipos de dados, bem como criar tabelas com variações e filhas para quaisquer matrizes nesses documentos. Para Couchbase Enterprise versão 4.5.1 e posterior, o conector também pode ser configurado para usar o comando INFER quando TypeDetectionScheme é definido como INFER. Isso permite que o conector obtenha uma listagem de coluna mais precisa para o depósito e detecte variações mais complexas.

Ao usar o serviço Analytics, o conector faz apenas a detecção de colunas e tabelas filhas. As tabelas com sabor são fornecidas pelo próprio Couchbase usando conjuntos de dados de sombra. Além disso, o modo Analítico atualmente não tem suporte INFER, portanto, apenas a varredura de linha é suportada.

Para obter mais detalhes, consulte Descoberta automática de esquema para ver como tabelas com variações e tabelas filhas são modeladas a partir dos dados do Couchbase. Contexto NumericStrings também é recomendado, pois pode evitar problemas de detecção de tipo com certos tipos de dados de texto.

Definições de esquema personalizado

Opcionalmente, você pode usar Definições de esquema personalizado para projetar sua estrutura relacional escolhida sobre um objeto Couchbase. Isso permite que você defina os nomes das colunas escolhidas, seus tipos de dados e as localizações de seus valores no documento Couchbase.

Mapeamento de consulta

Consulte Mapeamento de consulta para obter mais detalhes sobre como várias operações N1QL e SQL++ são representadas como SQL.

Achatamento Vertical

Consulte Achatamento vertical para obter mais detalhes sobre como matrizes e objetos são mapeados em campos.

Funções JSON

Consulte Funções JSON para obter mais detalhes sobre como extrair dados de strings JSON brutas.

Descoberta Automática de Esquema¶

Tabelas Filhas¶

Se os documentos em um depósito contiverem campos com matrizes, o conector exporá esses campos como suas próprias tabelas, além de expô-los como agregados JSON na tabela principal. A estrutura dessas tabelas filhas depende se a matriz contém objetos ou valores primitivos.

Tabelas Filhas de Matriz¶

Se os arrays contiverem valores primitivos como números ou strings, a tabela filha terá apenas duas colunas: uma chamada "Document.Id", que é a chave primária do documento que contém o array, e outra chamada "value", que contém o valor dentro a matriz. Por exemplo, se o bucket "Jogos" contiver estes documentos:

/* Primary key "1" */
{
  "scores": [1,2,3]
}

/* Primary key "2" */
{
  "scores": [4,5,6]
}

O conector criará uma tabela chamada "Games_scores" contendo estas linhas:

Tabelas Filhas de Objeto¶

Se os arrays contiverem objetos, a tabela filha terá uma coluna para cada campo que ocorre nos objetos, bem como uma coluna "Document.Id" que contém a chave primária do documento que contém o array. Por exemplo, se o bucket "Jogos" contiver estes documentos:

/* Primary key "1" */
{
  "moves": [
    {"piece": "pawn", "square": "c3"},
    {"piece": "rook", "square": "d5"}
  ]
}

/* Primary key "2" */
{
  "moves": [
    {"piece": "knight", "square": "f1"},
    {"piece": "bishop", "square": "e4"}
  ]
}

O conector criará uma tabela chamada "Games_moves" contendo estas linhas:

NewChildJoinsMode¶

Observe que o modelo de dados acima não é totalmente relacional, o que tem limitações importantes para casos de uso que envolvem JOINs complexos ou operações DML em tabelas filhas. O NewChildJoinsMode propriedade de conexão expõe um modelo de dados alternativo que evita essas limitações. Consulte sua página na seção de propriedades de conexão da documentação para obter mais detalhes.

Mesas Aromatizadas¶

O conector também pode detectar quando há vários tipos de documentos no mesmo compartimento, desde que TypeDetectionScheme é definido como Infer ou DocType e CouchbaseService é definido como N1QL. Esses diferentes tipos de documentos são expostos como suas próprias tabelas contendo apenas as linhas apropriadas.

Por exemplo, o bloco "Jogos" contém documentos que têm um valor de "tipo" de "xadrez" ou "futebol":

/* Primary key "1" */
{
  "type": "chess",
  "result": "stalemate"
}

/* Primary key "2" */
{
  "type": "chess",
  "result": "black win"
}

/* Primary key "3" */
{
  "type": "football",
  "score": 23
}

/* Primary key "4" */
{
  "type": "football",
  "score": 18
}

O conector criará três tabelas para este bucket: uma chamada "Games" que contém todos os documentos:

Um chamado "Games.chess" que contém apenas documentos onde o tipo é "chess":

E um chamado "Games.football" que contém apenas documentos onde o tipo é "football":

Observe que o conector não incluirá colunas em uma tabela de tipos que não estejam definidas nos documentos desse tipo. Por exemplo, embora as colunas "resultado" e "pontuação" estejam incluídas na tabela base, "Jogos.chess" inclui apenas "resultado" e "Jogos.futebol" inclui apenas "pontuação".

Mesas Infantis Aromatizadas¶

Também é possível que uma tabela com sabor contenha arrays, que se tornarão suas próprias tabelas filhas. Por exemplo, se o bucket "Jogos" contiver estes documentos:

/* Primary key "1" */
{
  "type": "chess",
  "results": ["stalemate", "white win"]
}

/* Primary key "2" */
{
  "type": "chess",
  "results": ["black win", "stalemate"]
}

/* Primary key "3" */
{
  "type": "football",
  "scores": [23, 12]
}

/* Primary key "4" */
{
  "type": "football",
  "scores": [18, 36]
}

Em seguida, o conector irá gerar estas tabelas:

Mapeamento de Consultas¶

O conector mapeia consultas compatíveis com SQL-92 em consultas N1QL ou SQL++ correspondentes. Embora o mapeamento abaixo não esteja completo, ele deve ajudá-lo a entender os padrões comuns que o conector usa durante essa transformação.

Consultas SELECT¶

As instruções SELECT são traduzidas para a consultar N1QL SELECT apropriada, conforme mostrado abaixo. Devido às semelhanças entre SQL-92 e N1QL, muitas consultas serão simplesmente traduções diretas.

Uma grande diferença é que, quando o esquema para um determinado bucket do Couchbase existe no conector, uma consultar SELECT * será convertida para selecionar diretamente os campos individuais no bucket. O conector também criará automaticamente um Document.Id coluna baseada na chave primária de cada documento no bucket.

Observe que as condições podem incluir funções de tipo extras se o conector detectar que uma conversão de tipo pode ser necessária. Você pode desabilitar essas conversões de tipo usando StrictComparison propriedade. Para maior clareza, o restante das amostras N1QL são mostradas sem essas funções de conversão extras.

USE KEYS Otimizações¶

Quando uma consultar tem cláusula igual ou IN que tem como alvo o Document.Id e não houver cláusula OR para substituí-la, o conector converterá o Document.Id filtro em uma cláusula USE KEYS. Isso evita a sobrecarga de escanear um índice porque as chaves do documento já são conhecidas pelo mecanismo N1QL (essa otimização não se aplica ao Analytics CouchbaseService).

Além de ser usado para consultas SELECT, a mesma otimização é realizada para operações DML conforme mostrado abaixo.

Tabelas Filhas¶

Contanto que todas as tabelas filhas em uma consultar compartilhem o mesmo pai e sejam combinadas usando INNER JOINs em seus Document.Id, o conector combinará os JOINs em uma única expressão UNNEST. Ao contrário das consultas N1QL UNNEST, você deve explicitamente JOIN com a tabela base se quiser acessar seus campos.

Tabelas de Sabores¶

Tabelas com sabor sempre têm a condição apropriada incluída quando você consultar, para que apenas os documentos do tipo sejam retornados:

Consultas Agregadas¶

O N1QL possui várias funções agregadas integradas. O conector faz uso extensivo disso para várias consultas agregadas. Veja alguns exemplos abaixo:

Inserir Declarações¶

A instrução SQL INSERT é mapeada para a instrução N1QL INSERT conforme mostrado abaixo. Isso funciona da mesma forma para campos de nível superior, bem como campos produzidos por Vertical Flattening:

Inserções de Tabela Filho¶

As inserções nas tabelas filhas são convertidas internamente em N1QL UPDATEs usando operações de array. Como isso não cria o documento de nível superior, o Document.Id fornecido deve se referir a um documento que já existe.

Outra limitação das inserções de tabelas filhas é que todas as inserções de vários valores devem usar o mesmo Document.Id. O provedor verificará isso antes de modificar qualquer dado e gerará um erro se essa restrição for violada.

Declarações de Inserção em Massa¶

Inserções em massa também são suportadas, a SQL Bulk Insert é convertida conforme mostrado abaixo:

INSERT INTO users#Temp([Document.Id], KEY, VALUE) VALUES('bcd001', 45, "A")
INSERT INTO users#Temp([Document.Id], KEY, VALUE) VALUES('bcd002', 24, "B")
INSERT INTO users SELECT * FROM users#Temp

é convertido em:

INSERT INTO `Usuários` (KEY, VALUE) VALUES
  ('bcd001', {"age": 45, "status": "A"}),
('bcd002', {"age": 24, "status": "B"})

Assim como inserções de vários valores em tabelas filhas, todas as linhas em uma inserção em massa também devem ter o mesmo Document.Id.

Atualizar Extratos¶

A instrução SQL UPDATE é mapeada para a instrução N1SQL UPDATE conforme mostrado abaixo:

Atualizações da Tabela Filha¶

Ao atualizar uma tabela filho, a consultar SQL é convertida em uma consultar UPDATE usando uma expressão "FOR" ou uma expressão "ARRAY":

Atualizações da Tabela de Sabores¶

Assim como os SELECTs da tabela de variações, os UPDATEs nas tabelas de variações sempre incluem a condição apropriada, portanto, apenas os documentos pertencentes à variação são afetados:

Excluir Declarações¶

A instrução SQL DELETE é mapeada para a instrução N1QL DELETE conforme mostrado abaixo:

Exclusões da Tabela Filha¶

Ao excluir de uma tabela filho, a consultar SQL é convertida em uma consultar UPDATE usando uma expressão "ARRAY":

Exclusões de Tabelas de Sabores¶

Assim como os SELECTs da tabela de variações, os DELETEs nas tabelas de variações sempre incluem a condição apropriada, portanto, apenas os documentos pertencentes à variação são afetados:

Achatamento Vertical¶

Exemplo de Documento¶

/* Primary key "1" */
{
  "address" : {
    "building" : "1007",
    "coord" : [-73.856077, 40.848447],
    "street" : "Morris Park Ave",
    "zipcode" : "10462"
  },
  "borough" : "Bronx",
  "cuisine" : "Bakery",
  "grades" : [{
      "date" : "2014-03-03T00:00:00Z",
      "grade" : "A",
      "score" : 2
    }, {
      "date" : "2013-09-11T00:00:00Z",
      "grade" : "A",
      "score" : 6
    }, {
      "date" : "2013-01-24T00:00:00Z",
      "grade" : "A",
      "score" : 10
    }, {
      "date" : "2011-11-23T00:00:00Z",
      "grade" : "A",
      "score" : 9
    }, {
      "date" : "2011-03-10T00:00:00Z",
      "grade" : "B",
      "score" : 14
    }],
  "name" : "Morris Park Bake Shop",
  "restaurant_id" : "30075445"
}

Selecionando Valores em Objetos¶

Se o FlattenObjects está configurada para permitir o nivelamento do objeto, então o conector percorrerá os objetos e mapeará os campos dentro deles como colunas. Por exemplo, esta consultar:

SELECT [address.building], [endereço.rua] FROM restaurants

Retornaria este conjunto de resultados:

Selecionando Valores em Matrizes¶

Se o FlattenArrays estiver configurada para permitir o nivelamento de matriz, o conector percorrerá as matrizes e mapeará seus valores individuais como colunas. Por exemplo, se Flatten Arrays foram definidos como "2", então esta consultar:

SELECT [address.coord.0], [endereço.coord.1] FROM restaurants

Retornaria este conjunto de resultados:

Observe que o nivelamento do array só deve ser usado nos casos em que você sabe o número de itens do array com antecedência, como em "address.coord", que sempre conterá dois itens. Para arrays como "grades" que podem conter números arbitrários de itens, considere usar as tabelas filhas descritas em Automatic Schema Discovery em vez disso, pois eles permitirão que você leia todos os valores dentro da matriz.

Funções Definidas pelo Usuário¶

As funções definidas pelo usuário são um novo recurso fornecido pelo Couchbase 7 e superior. Eles podem ser usados com o conector como funções normais, mas com uma convenção de nomenclatura especial para usar funções com escopo. Normalmente o conector requer que as funções já existam antes de serem usadas, para defini-las consulte a documentação do Couchbase em CREATE FUNCTION consultas. Estes podem ser executados no console Couchbase ou com o conector em QueryPassthrough modo.

O Couchbase tem suporte tanto para funções escalares quanto para funções que retornam resultados de subconsultas. O conector oferece suporte a funções escalares em seu dialeto SQL, mas as funções de subconsulta só podem ser usadas quando QueryPassthrough está ativado. O restante desta seção aborda o dialeto SQL do conector e assume que QueryPassthrough está desabilitado.

Funções Globais¶

Tanto no modo N1QL quanto no modo Analytics, as funções globais definidas pelo usuário podem ser acessadas usando seus nomes simples ou qualificados. O nome simples é apenas o nome da função:

SELECT ageInYears(birthdate) FROM users

As funções globais também podem ser invocadas qualificando-as com o namespace padrão. Nomes qualificados são nomes entre aspas que contêm separadores internos, que por padrão é um ponto, embora isso possa ser alterado usando DataverseSeparator propriedade. Tanto no N1QL quanto no Analytics, o namespace global é chamado Default:

SELECT [Default.ageInYears](data de nascimento) FROM users

Chamar funções globais usando nomes simples é recomendado. Embora o qualificador padrão seja suportado, seu único uso pretendido é quando um UDF entra em conflito com uma função SQL padrão que o conector traduziria de outra forma.

Funções com Escopo¶

Tanto o N1QL quanto o Analytics também permitem que as funções sejam definidas fora de um contexto global. No Analytics, as funções podem ser anexadas a dataverses e escopos que são chamados usando nomes de duas e três partes, respectivamente. Em N1QL, as funções só podem ser anexadas a escopos, portanto, apenas nomes de três partes podem ser usados.

/* N1QL AND Analytics */
SELECT [socialNetwork.accounts.ageInYears](data de nascimento) FROM [socialNetwork.accounts.users]

/* Analytics only */
SELECT [socailNetwork.ageInYears](data de nascimento) FROM [socialNetwork.accounts.users]

Funções JSON¶

O conector pode retornar estruturas JSON como valores de coluna. O conector permite usar funções SQL padrão para trabalhar com essas estruturas JSON. Os exemplos nesta seção usam a seguinte matriz:

[
     { "grade": "A", "score": 2 },
     { "grade": "A", "score": 6 },
     { "grade": "A", "score": 10 },
     { "grade": "A", "score": 9 },
     { "grade": "B", "score": 14 }
]

JSON_EXTRACT¶

A função JSON_EXTRACT pode extrair valores individuais de um objeto JSON. A consultar a seguir retorna os valores mostrados abaixo com base no caminho JSON passado como o segundo argumento para a função:

SELECT Name, JSON_EXTRACT(grades,'[0].grade') AS Grade, JSON_EXTRACT(grades,'[0].score') AS Score FROM Students;

JSON_COUNT¶

A função JSON_COUNT retorna o número de elementos em uma matriz JSON dentro de um objeto JSON. A consultar a seguir retorna o número de elementos especificados pelo caminho JSON passado como o segundo argumento para a função:

SELECT Name, JSON_COUNT(grades,'[x]') AS NumberOfGrades FROM Students;

JSON_SUM¶

A função JSON_SUM retorna a soma dos valores numéricos de uma matriz JSON em um objeto JSON. A consultar a seguir retorna o total dos valores especificados pelo caminho JSON passado como o segundo argumento da função:

SELECT Name, JSON_SUM(score,'[x].score') AS TotalScore FROM Students;

JSON_MIN¶

A função JSON_MIN retorna o menor valor numérico de uma matriz JSON dentro de um objeto JSON. A consultar a seguir retorna o valor mínimo especificado pelo caminho JSON passado como o segundo argumento para a função:

SELECT Name, JSON_MIN(score,'[x].score') AS LowestScore FROM Students;

JSON_MAX¶

A função JSON_MAX retorna o valor numérico mais alto de uma matriz JSON dentro de um objeto JSON. A consultar a seguir retorna o valor máximo especificado pelo caminho JSON passado como o segundo argumento para a função:

SELECT Name, JSON_MAX(score,'[x].score') AS HighestScore FROM Students;

DOCUMENTO¶

A função DOCUMENT pode ser usada para retornar um documento como uma string JSON. DOCUMENT(*) pode ser usado com qualquer tipo de consultar SELECT, incluindo consultas incluindo outras colunas, consultas incluindo apenas DOCUMENT(*) e consultas ainda mais complexas como JOINs.

SELECT [ID do documento], grade, score, DOCUMENT(*) FROM grades

Por exemplo, essa consultar retornaria:

Quando usado sozinho, DOCUMENT(*) retorna a estrutura diretamente do Couchbase como se uma consultar N1QL ou SQL++ SELECT * fosse usada. Isso significa que nenhum valor Document.Id estará presente, pois o Couchbase não o inclui automaticamente.

SELECT DOCUMENT(*) FROM grades

Esta consultar retornaria:

Definições de Esquema Personalizado¶

Além da descoberta automática de esquema o conector também permite definir estaticamente o esquema para seu objeto Couchbase. Os esquemas são definidos em arquivos de configuração baseados em texto, o que os torna fáceis de estender. Você pode chamar o método CreateSchema procedimento armazenado* para gerar um arquivo de esquema; consulte Descoberta Automática de Esquema Para maiores informações.

Colocou o Location para o diretório do arquivo que conterá o arquivo de esquema. As seções a seguir mostram como estender o esquema resultante ou escrever o seu próprio.

Exemplo de Documento¶

Vamos considerar o documento abaixo e extrair as propriedades aninhadas como suas próprias colunas:

/* Primary key "1" */
{
  "id": 12,
  "name": "Lohia Manufacturers Inc.",
  "homeaddress": {"street": "Main "Street", "city": "Chapel Hill", "state": "NC"},
  "workaddress": {"street": "10th "Street", "city": "Chapel Hill", "state": "NC"}
  "offices": ["Chapel Hill", "London", "New York"]
  "annual_revenue": 35600000
}
/* Primary key "2" */
{
  "id": 15,
  "name": "Piago Industries",
  "homeaddress": {street": "Main Street", "city": "San Francisco", "state": "CA"},
  "workaddress": {street": "10th Street", "city": "San Francisco", "state": "CA"}
  "offices": ["Durham", "San Francisco"]
  "annual_revenue": 42600000
}

Definição de Esquema Personalizado¶

<rsb:info title="Customers" description="Customers" other:dataverse="" other:bucket=customers"" other:flavorexpr="" other:flavorvalue="" other:isarray="false" other:pathspec="" other:childpath="">
  <attr name="document.id"        xs:type="string"  key="true" other:iskey="true" other:pathspec=""  />
  <attr name="annual_revenue"     xs:type="integer" other:iskey="false"           other:pathspec=""  other:field="annual_revenue" />
  <attr name="homeaddress.city"   xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="homeaddress.city" />
  <attr name="homeaddress.state"  xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="homeaddress.state" />
  <attr name="homeaddress.street" xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="homeaddress.street" />
  <attr name="name"               xs:type="string"  other:iskey="false"           other:pathspec=""  other:field="name" />
  <attr name="id"                 xs:type="integer" other:iskey="false"           other:pathspec=""  other:field="id" />
  <attr name="offices"            xs:type="string"  other:iskey="false"           other:pathspec=""  other:field="offices" />
  <attr name="offices.0"          xs:type="string"  other:iskey="false"           other:pathspec="[" other:field="offices.0" />
  <attr name="offices.1"          xs:type="string"  other:iskey="false"           other:pathspec="[" other:field="offices.1" />
  <attr name="workaddress.city"   xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="workaddress.city" />
  <attr name="workaddress.state"  xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="workaddress.state" />
  <attr name="workaddress.street" xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="workaddress.street" />
</rsb:info>

Em Exemplo de esquema personalizado, você encontrará o esquema completo que contém o exemplo acima.

Propriedades da Tabela¶

O esquema acima usa as seguintes propriedades para definir qualidades específicas para toda a tabela. Todos eles são necessários:

Propriedades da Coluna¶

O esquema acima usa as seguintes propriedades para definir qualidades específicas para cada coluna:

Observe que os campos produzidos pelo nivelamento vertical usam a mesma sintaxe para separar valores de matriz e valores de campo. Isso introduz uma possível ambiguidade em casos como o seguinte, em que o conector expõe as colunas "numeric_object.0" e "array.0":

{
  "numeric_object": {
    "0": 0
  },
  "array": [
    0
  ]
}

Para garantir que o conector possa distinguir entre acessos de campo e array, o pathspec é usado para determinar se cada "." no campo é uma matriz ou um objeto. Cada "{" representa um acesso de campo, enquanto cada "[" representa um acesso de array.

Por exemplo, com um campo de "a.0.b.1" e um "pathspec" de "[{[", a expressão N1QL "a[0].b[1]" seria gerado. Se, em vez disso, o "pathspec" fosse "{{{", then the N1QL expression "a.`0`.b.`1`" seria gerado.

Exemplo de Esquema Personalizado¶

Esta seção contém um esquema completo. Colocou o Location para o diretório do arquivo que conterá o arquivo de esquema. A seção info permite uma visualização relacional de um objeto Couchbase. Para obter mais detalhes, consulte Definições de esquema personalizado. A tabela abaixo permite os comandos SELECT, INSERT, UPDATE e DELETE conforme implementados nas seções GET, POST, MERGE e DELETE do esquema abaixo. As operações, como couchbaseadoSysData, são implementações internas.

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">
  <rsb:info title="Customers" description="Customers" other:dataverse="" other:bucket=customers"" other:flavorexpr="" other:flavorvalue="" other:isarray="false" other:pathspec="" other:childpath="">
    <attr name="document.id"        xs:type="string"  key="true" other:iskey="true" other:pathspec=""  />
    <attr name="annual_revenue"     xs:type="integer" other:iskey="false"           other:pathspec=""  other:field="annual_revenue" />
    <attr name="homeaddress.city"   xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="homeaddress.city" />
    <attr name="homeaddress.state"  xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="homeaddress.state" />
    <attr name="homeaddress.street" xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="homeaddress.street" />
    <attr name="name"               xs:type="string"  other:iskey="false"           other:pathspec=""  other:field="name" />
    <attr name="id"                 xs:type="integer" other:iskey="false"           other:pathspec=""  other:field="id" />
    <attr name="offices"            xs:type="string"  other:iskey="false"           other:pathspec=""  other:field="offices" />
    <attr name="offices.0"          xs:type="string"  other:iskey="false"           other:pathspec="[" other:field="offices.0" />
    <attr name="offices.1"          xs:type="string"  other:iskey="false"           other:pathspec="[" other:field="offices.1" />
    <attr name="workaddress.city"   xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="workaddress.city" />
    <attr name="workaddress.state"  xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="workaddress.state" />
    <attr name="workaddress.street" xs:type="string"  other:iskey="false"           other:pathspec="{" other:field="workaddress.street" />
  </rsb:info>
</rsb:script>

Características Avançadas¶

Esta seção detalha uma seleção de recursos avançados do conector Couchbase.

Visualizações definidas pelo usuário

O conector permite definir tabelas virtuais, denominadas visões definidas pelo usuário, cujo conteúdo é decidido por uma consultar pré-configurada. Essas exibições são úteis quando você não pode controlar diretamente as consultas enviadas aos drivers. Consulte Visualizações definidas pelo usuário para obter uma visão geral da criação e configuração de exibições personalizadas.

Configuração SSL

Use Configuração SSL para ajustar como o conector lida com as negociações de certificado TLS/SSL. Você pode escolher entre vários formatos de certificado; Veja o SSLServerCert propriedade em "Opções de cadeia de conexão" para obter mais informações.

Procurador

Para configurar o conector usando configurações de proxy do Agente Privado, selecione os Use Proxy Settings caixa de seleção na tela de configuração da conexão.

Visualizações Definidas pelo Usuário¶

O Jitterbit Connector for Couchbase permite definir uma tabela virtual cujo conteúdo é decidido por uma consultar pré-configurada. Elas são chamadas de Visualizações Definidas pelo Usuário, que são úteis em situações onde você não pode controlar diretamente a consultar que está sendo emitida para o driver, por exemplo, ao usar o driver do Jitterbit. As Visualizações Definidas pelo Usuário podem ser usadas para definir predicados que são sempre aplicados. Se você especificar predicados adicionais na consultar para a visualização, eles serão combinados com a consultar já definida como parte da visualização.

Há duas maneiras de criar exibições definidas pelo usuário:

• Crie um arquivo de configuração em formato JSON definindo as visualizações desejadas.
• declarações DDL.

Definindo Visualizações Usando um Arquivo de Configuração¶

As visualizações definidas pelo usuário são definidas em um arquivo de configuração formatado em JSON chamado UserDefinedViews.json. O conector detecta automaticamente as visualizações especificadas neste arquivo.

Você também pode ter várias definições de exibição e controlá-las usando o UserDefinedViews propriedade de conexão. Quando você usa essa propriedade, apenas as exibições especificadas são vistas pelo conector.

Este arquivo de configuração de exibição definida pelo usuário é formatado da seguinte forma:

• Cada elemento raiz define o nome de uma exibição.
• Cada elemento raiz contém um elemento filho, chamado query, que contém a consultar SQL personalizada para a visualização.

Por exemplo:

{
    "MyView": {
        "query": "SELECT * FROM Customer WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Use o UserDefinedViews propriedade de conexão para especificar a localização do seu arquivo de configuração JSON. Por exemplo:

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Esquema para Exibições Definidas pelo Usuário¶

As visualizações definidas pelo usuário são expostas no UserViews esquema por padrão. Isso é feito para evitar que o nome da exibição entre em conflito com uma entidade real no modelo de dados. Você pode alterar o nome do esquema usado para UserViews definindo o UserViewsSchemaName propriedade.

Trabalhando com Exibições Definidas pelo Usuário¶

Por exemplo, uma instrução SQL com uma Visualização Definida pelo Usuário chamada UserViews.RCustomers lista apenas clientes em Raleigh:

SELECT * FROM Customers WHERE City = 'Raleigh';

Exemplo de consultar ao driver:

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

Resultando na consultar efetiva à fonte:

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

Esse é um exemplo muito simples de uma consultar a uma exibição definida pelo usuário que é efetivamente uma combinação da consultar de exibição e da definição de exibição. É possível compor essas consultas em padrões muito mais complexos. Todas as operações SQL são permitidas em ambas as consultas e são combinadas quando apropriado.

Configuração SSL¶

Personalizando a Configuração SSL¶

Por padrão, o conector tenta negociar SSL/TLS verificando o certificado do servidor em relação ao armazenamento de certificados confiáveis do sistema.

Para especificar outro certificado, consulte o SSLServerCert propriedade para os formatos disponíveis para fazê-lo.

Certificados SSL do Cliente¶

O conector Couchbase também oferece suporte à configuração de certificados de cliente. Defina o seguinte para se conectar usando um certificado de cliente.

• SSLClientCert: O nome do armazenamento de certificados para o certificado do cliente.
• SSLClientCertType: O tipo de armazenamento de chaves que contém o certificado de cliente TLS/SSL.
• SSLClientCertPassword: A senha para o certificado do cliente TLS/SSL.
• SSLClientCertSubject: O assunto do certificado de cliente TLS/SSL.

Modelo de Dados¶

Visão geral

Dependendo das configurações de conexão que estão sendo usadas, o conector pode apresentar vários mapeamentos diferentes entre entidades Couchbase e tabelas e exibições relacionais. Para obter mais detalhes sobre cada um desses recursos, consulte a parte NoSQL desta documentação.

• Ao conectar-se ao serviço de consultar N1QL, o conector modela os depósitos Couchbase como tabelas relacionais. Além disso, se TypeDetectionScheme for definido como DocType ou Infer, o conector apresentará diferentes tipos de documento em cada compartimento como suas próprias tabelas.
• Ao conectar-se ao serviço Analytics, o conector modela conjuntos de dados Couchbase como exibições relacionais.
• Ao se conectar com qualquer um dos serviços, o conector pode expor matrizes de dados como tabelas ou exibições filhas.

Consulte a Descoberta automática de esquema para obter mais detalhes sobre como as tabelas de variações e filhas são expostas. Além disso, o NewChildJoinsMode a propriedade de conexão é recomendada para workflows que fazem uso intenso de tabelas filhas. A documentação dessa propriedade de conexão detalha as melhorias feitas no modelo de dados do conector.

Dataversos, Escopos e Coleções

O Couchbase tem diferentes maneiras de agrupar buckets e conjuntos de dados, dependendo do CouchbaseService e a versão do Couchbase à qual você está se conectando:

• O Couchbase organiza conjuntos de dados do Analytics em grupos chamados dataverses. Por padrão, o conector expõe conjuntos de dados de todos os dataverses usando nomes compostos como Default.users conforme descrito em DataverseSeparator. É importante lembrar que esses nomes compostos devem vir entre aspas quando usados em consultas, por exemplo SELECT * FROM [Default.users]
• Você também pode definir o Dataverse propriedade para limitar o conector a expor um único dataverse. Isso desativa os nomes compostos para que os nomes das visualizações não incluam o conjunto de dados.
• Ao conectar-se ao Couchbase 7 e superior, o conector usará o escopo, a coleção e o nome do bloco/conjunto de dados para criar tabelas e exibir nomes. Por exemplo, uma tabela com um nome como crm.accounts.customers expõe o customers coleção sob o accounts escopo do crm balde. Estes devem ser citados da mesma forma que outros nomes compostos quando usados em consultas, por exemplo SELECT * FROM [crm.accounts.customers]

Metadados ativos

Todos os esquemas fornecidos pelo conector são recuperados dinamicamente do Couchbase, portanto, quaisquer alterações nos depósitos ou campos no Couchbase serão refletidas no conector na próxima vez que você se conectar. Você também pode emitir uma consultar de redefinição para atualizar os esquemas sem precisar fechar a conexão:

RESET SCHEMA CACHE

Procedimentos Armazenados¶

Procedimentos armazenados* estão disponíveis para complementar os dados disponíveis no Modelo de Dados. Pode ser necessário atualizar os dados disponíveis em uma exibição usando um procedimento armazenado* porque os dados não fornecem atualizações bidirecionais diretas, semelhantes a tabelas. Nessas situações, a recuperação dos dados é feita usando a visualização ou tabela apropriada, enquanto a atualização é feita chamando um procedimento armazenado. Procedimentos armazenados* pega uma lista de parâmetros e retorna um conjunto de dados que contém a coleção de tuplas que constituem a resposta.

Conector Jitterbit para Procedimentos Armazenados Couchbase¶

AdicionarDocumento¶

Faça o upsert de documentos JSON inteiros no Couchbase no estado em que se encontram.

Entrada¶

Colunas do Conjunto de Resultados¶

CriarBalde¶

Cria um novo balde no CouchBase.

Criando Baldes¶

Buckets usando @AuthType 'none' podem ser criados especificando apenas @Name, @AuthType, @BucketType e @RamQuotaMB. A opção @ProxyPort também pode ser necessária, dependendo da versão do Couchbase à qual você está se conectando.

EXECUTE CreateBucket
  @Name = 'Players',
  @AuthType = 'NONE',
  @BucketType = 'COUCHBASE',
  @RamQuotaMB = 100,
@ProxyPort = 1234

Ao criar um depósito com @AuthType 'sasl', o @ProxyPort não deve ser fornecido e o @SaslPassword é opcional:

EXECUTE CreateBucket
  @Name = 'Players',
  @AuthType = 'SASL',
  @BucketType = 'COUCHBASE',
@RamQuotaMB = 100

Todos os outros parâmetros podem ser usados independentemente de qual @AuthType você fornecer.

Entrada¶

Colunas do Conjunto de Resultados¶

CriarColeção¶

Cria uma coleção em um escopo existente

Entrada¶

Colunas do Conjunto de Resultados¶

Criar Esquema¶

Cria uma definição de esquema de uma tabela no Couchbase. Os resultados podem mudar dependendo do valor de FlattenObjects, FlattenArrays e TypeDetectionScheme.

Entrada¶

Colunas do Conjunto de Resultados¶

Criar Escopo¶

Cria um escopo em um bucket existente

Entrada¶

Colunas do Conjunto de Resultados¶

CreateUserTable¶

Uma operação interna usada quando GenerateSchemaFiles=OnCreate

Note: Este procedimento faz uso de indexed parameters. Esses parâmetros de entrada são indicados com um # no final de seus nomes.

Os parâmetros indexados facilitam o fornecimento de várias instâncias de um único parâmetro como entradas para o procedimento.

Suponha que haja um parâmetro de entrada chamado Param#. Insira várias instâncias de um parâmetro indexado como este:

EXEC ProcedureName Param#1 = "value1", Param#2 = "value2", Param#3 = "value3"

Entrada¶

Colunas do Conjunto de Resultados¶

DeleteBucket¶

Exclui um bucket (e todas as suas coleções e escopos, quando suportados)

Entrada¶

Colunas do Conjunto de Resultados¶

ExcluirColeção¶

Exclui uma coleção (Couchbase 7 e superior)

Entrada¶

Colunas do Conjunto de Resultados¶

DeleteScope¶

Exclui um escopo e todas as suas coleções (Couchbase 7 e superior)

Entrada¶

Colunas do Conjunto de Resultados¶

FlushBucket¶

Remove todos os documentos de um depósito no Couchbase.

Entrada¶

Colunas do Conjunto de Resultados¶

ListIndices¶

Lista todos os índices disponíveis no Couchbase

Colunas do Conjunto de Resultados¶

ManageIndices¶

Cria/descarta um índice em um depósito de destino no Couchbase.

Índices de Construção¶

Um índice primário anônimo pode ser criado com estes parâmetros:

EXECUTE ManageIndices
  @BucketName = 'Players'
  @Action = 'CREATE'
  @IsPrimary = 'true'
@IndexType = 'VIEW'

Isso é o mesmo que executar este N1QL:

CREATE PRIMARY INDEX ON `Jogadoras` USING VIEW

Um índice primário nomeado pode ser criado especificando um @Name, além dos parâmetros listados acima:

EXECUTE ManageIndices
  @BucketName = 'Players'
  @Action = 'CREATE'
  @IsPrimary = 'true'
  @Name = 'Players_primary'
@IndexType = 'VIEW'

Um índice secundário pode ser criado definindo @IsPrimary como false e fornecendo pelo menos uma expressão.

EXECUTE ManageIndices
  @BucketName = 'Players',
  @Action = 'CREATE',
  @IsPrimary = 'false',
  @Name = 'Players_playtime_score',
@Expressions = '["score", "playtime"]'

Isso é o mesmo que executar o seguinte N1QL:

CREATE INDEX `Players_playtime_score` ON `Jogadoras`(score, playtime) USING GSI;

Vários nós e filtros também podem ser fornecidos para gerar índices mais complexos. Eles devem ser fornecidos como listas JSON:

EXECUTE ManageIndices
  @BucketName = 'Players',
  @Name = 'TopPlayers',
  @Expressions = '["score", "playtime"]',
  @Filter = '["topscore > 1000", "playtime > 600"]',
@Nodes = '["127.0.0.1:8091", "192.168.0.100:8091"]'

Isso é o mesmo que executar o seguinte N1QL:

CREATE INDEX `Melhores jogadores` ON `Jogadoras`(score, playtime) WHERE topscore > 1000 AND playtime > 600 USING GSI WITH { "nodes": ["127.0.0.1:8091", "192.168.0.100:8091"]};

Entrada¶

Colunas do Conjunto de Resultados¶

Tabelas do Sistema¶

Você pode consultar as tabelas do sistema descritas nesta seção para acessar informações de esquema, informações sobre a funcionalidade da fonte de dados e estatísticas de operação em lote.

Tabelas de Esquema¶

As tabelas a seguir retornam os metadados do banco de dados para o Couchbase:

• sys_catalogs: Lista os bancos de dados disponíveis.
• sys_schemas: Lista os esquemas disponíveis.
• sys_tables: Lista as tabelas e exibições disponíveis.
• sys_tablecolumns: Descreve as colunas das tabelas e exibições disponíveis.
• sys_procedures: Descreve os procedimentos armazenados disponíveis.
• sys_procedureparameters: Descreve procedimento armazenado* parâmetros.
• sys_keycolumns: Descreve as chaves primárias e estrangeiras.
• sys_indexes: Descreve os índices disponíveis.

Tabelas de Fonte de Dados¶

As tabelas a seguir retornam informações sobre como se conectar e consultar a fonte de dados:

• sys_connection_props: Retorna informações sobre as propriedades de conexão disponíveis.
• sys_sqlinfo: Descreve as consultas SELECT que o conector pode descarregar para a fonte de dados.

Consultar Tabelas de Informações¶

A tabela a seguir retorna estatísticas de consultar para consultas de modificação de dados:

• sys_identity: Retorna informações sobre operações em lote ou atualizações únicas.

Sys_catalogs¶

Lista os bancos de dados disponíveis.

A consultar a seguir recupera todos os bancos de dados determinados pela string de conexão:

SELECT * FROM sys_catalogs

Colunas¶

Sys_schemas¶

Lista os esquemas disponíveis.

A consultar a seguir recupera todos os esquemas disponíveis:

SELECT * FROM sys_schemas

Colunas¶

Sys_tables¶

Lista as tabelas disponíveis.

A consultar a seguir recupera as tabelas e exibições disponíveis:

SELECT * FROM sys_tables

Colunas¶

Sys_tablecolumns¶

Descreve as colunas das tabelas e exibições disponíveis.

A consultar a seguir retorna as colunas e os tipos de dados da tabela Customer:

SELECT ColumnName, DataTypeName FROM sys_tablecolumns WHERE TableName='Customer' 

Colunas¶

Sys_procedures¶

Lista os procedimentos armazenados disponíveis.

A consultar a seguir recupera os procedimentos armazenados disponíveis:

SELECT * FROM sys_procedures

Colunas¶

Sys_procedureparameters¶

Descreve procedimento armazenado* parâmetros.

A consultar a seguir retorna informações sobre todos os parâmetros de entrada para o procedimento armazenado SelectEntries:

SELECT * FROM sys_procedureparameters WHERE ProcedureName='SelectEntries' AND Direction=1 OR Direction=2

Colunas¶

Sys_keycolumns¶

Descreve as chaves primárias e estrangeiras. A consultar a seguir recupera a chave primária da tabela Customer:

SELECT * FROM sys_keycolumns WHERE IsKey='True' AND TableName='Customer'

Colunas¶

Sys_foreignkeys¶

Descreve as chaves estrangeiras. A consultar a seguir recupera todas as chaves estrangeiras que se referem a outras tabelas:

SELECT * FROM sys_foreignkeys WHERE ForeignKeyType = 'FOREIGNKEY_TYPE_IMPORT'

Colunas¶

Sys_indexes¶

Descreve os índices disponíveis. Ao filtrar por índices, você pode escrever consultas mais seletivas com tempos de resposta de consultar mais rápidos.

A consultar a seguir recupera todos os índices que não são chaves primárias:

SELECT * FROM sys_indexes WHERE IsPrimary='false'

Colunas¶

Sys_connection_props¶

Retorna informações sobre as propriedades de conexão disponíveis e as definidas na string de conexão.

Ao consultar esta tabela, a string de conexão de configuração deve ser usada:

jdbc:cdata:couchbase:config:

Esta string de conexão permite que você consultar esta tabela sem uma conexão válida.

A consultar a seguir recupera todas as propriedades de conexão que foram definidas na string de conexão ou definidas por meio de um valor padrão:

SELECT * FROM sys_connection_props WHERE Value <> ''

Colunas¶

Sys_sqlinfo¶

Descreve o processamento da consultar SELECT que o conector pode transferir para a fonte de dados.

Processamento de Consultas Colaborativas¶

Ao trabalhar com fontes de dados que não suportam SQL-92, você pode consultar a exibição sys_sqlinfo para determinar os recursos de consultar das APIs subjacentes, expressas na sintaxe SQL.

Descobrindo os Recursos SELECT da Fonte de Dados¶

Abaixo está um exemplo de conjunto de dados de recursos SQL. Alguns aspectos da funcionalidade SELECT são retornados em uma lista separada por vírgulas, se suportados; caso contrário, a coluna contém NO.

A consultar a seguir recupera os operadores que podem ser usados na cláusula WHERE:

SELECT * FROM sys_sqlinfo WHERE Name='SUPPORTED_OPERATORS'

Observe que tabelas individuais podem ter diferentes limitações ou requisitos na cláusula WHERE; consulte o Modelo de Dados para obter mais informações.

Colunas¶

Sys_identity¶

Retorna informações sobre tentativas de modificação.

A consultar a seguir recupera os IDs das linhas modificadas em uma operação em lote:

SELECT * FROM sys_identity

Colunas¶

Propriedades de Configurações Avançadas¶

As propriedades de configurações avançadas são as várias opções que podem ser usadas para estabelecer uma conexão. Esta seção fornece uma lista completa das opções que você pode configurar. Clique nos links para mais detalhes.

Autenticação

SSL

Esquema

Diversos

Autenticação¶

Esta seção fornece uma lista completa de propriedades de autenticação que você pode configurar.

AuthScheme¶

O tipo de autenticação a ser usado ao conectar-se ao Couchbase.

Valores Possíveis¶

Auto, Basic, CredentialsFile, SSLCertificate

Tipo de Dados¶

string

Valor Padrão¶

"Auto"

Observações¶

• Auto: esta opção é obsoleta e incluída apenas para compatibilidade.
• Básico: Usa a autenticação básica HTTP com Usuário e senha.
• CredentialsFile: Usa um arquivo de credenciais. Isso exigirá que CredentialsFile seja definida.
• SSLCertificate: Usa autenticação de certificado de cliente SSL. Requer que UseSSL seja habilitado e que SSLClientCert e SSLClientCertType ser definido.

Observe que apenas a autenticação básica é suportada ao usar o Cloud ConnectionMode.

Do Utilizador¶

A conta de usuário do Couchbase usada para autenticação.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Juntamente com Senha, este campo é usado para autenticação no servidor Couchbase.

Senha¶

A senha usada para autenticar o usuário.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

O usuário e Password são usados juntos para autenticar com o servidor.

CredenciaisArquivo¶

Use esta propriedade se precisar fornecer credenciais para vários usuários ou depósitos. Este arquivo tem prioridade sobre outras formas de autenticação.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Use esta propriedade se precisar fornecer credenciais para vários usuários ou depósitos. Isso tem prioridade sobre outras formas de autenticação.

Definir CredentialsFile para o caminho para um arquivo que tenha a mesma marcação abaixo:

[{"user": "YourUserName1", "pass":"YourPassword1"},
{"user": "YourUserName2", "pass":"YourPassword2"}] 

Servidor¶

O endereço do servidor ou servidores Couchbase aos quais você está se conectando.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Esse valor pode ser definido como um nome de host ou um endereço IP, como "couchbase-server.com" ou "1.2.3.4". Também pode ser definido como um URL HTTP ou HTTPS, como "https://couchbase-server.com ou "http://1.2.3.4. Se ConnectionMode estiver definido como Cloud, esse deve ser o nome do host da instância do Couchbase Cloud, conforme relatado no painel de controle.

Se o formulário de URL for usado, definir essa opção também definirá o UsarSSL opção: se o esquema de URL for "https://, então UseSSL será definido como verdadeiro e um URL com "http:// definirá UsarSSL para falso.

Um valor de porta não pode ser usado como parte desta opção, então valores como "http://couchbase-server.com:8093 não é permitido. Use WebConsolePort, N1QLPort e AnalyticsPort.

Esse valor também pode aceitar vários servidores no formato acima separados por vírgulas, como "1.2.3.4, couchbase-server.com". Isso permitirá que o conector recupere a conexão caso alguns dos servidores listados estejam inacessíveis.

Observe que, embora o conector tente recuperar a conexão como um todo, ele pode perder operações individuais. Por exemplo, enquanto uma consultar de execução longa falhará se o servidor ficar inacessível enquanto essa consultar estiver em execução, essa consultar poderá ser repetida na mesma conexão e o conector a executará no próximo servidor ativo.

CouchbaseService¶

Determina o serviço Couchbase ao qual se conectar. O padrão é N1QL. As opções disponíveis são N1QL e Analytics.

Valores Possíveis¶

N1QL, Analytics

Tipo de Dados¶

string

Valor Padrão¶

"N1QL"

Observações¶

Determina o serviço Couchbase ao qual se conectar. O padrão é N1QL. As opções disponíveis são N1QL e Analytics

Modo de Conexão¶

Determina como se conectar ao servidor Couchbase. Deve ser Direto ou Nuvem.

Valores Possíveis¶

Direct, Cloud

Tipo de Dados¶

string

Valor Padrão¶

"Direct"

Observações¶

Por padrão, o conector se conecta ao Couchbase diretamente usando o endereço fornecido no Servidor opção. O servidor deve estar executando o CouchbaseService para aceitar a conexão. Isso funcionará na maioria das implantações de nuvem no local ou básicas.

Isso deve ser definido como Cloud ao conectar-se ao Couchbase Cloud ou uma implantação personalizada que usa registros de serviço. Esses registros permitirão que o conector determine os servidores Couchbase exatos que fornecem o CouchbaseService. Você também deve definir o DNSServer para que o conector possa buscar esses registros de serviço.

Observe que habilitar o modo Cloud substituirá essas propriedades de conexão com os valores descobertos entrando em contato com o cluster:

• Servidor
• N1QLPort
• AnalyticsPort

Servidor Dns¶

Determina qual servidor DNS usar ao recuperar informações do Couchbase Cloud.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Na maioria dos casos, qualquer servidor DNS público pode ser fornecido aqui, como os fornecidos por OpenDNS, Cloudflare ou Google.

Se eles não estiverem acessíveis, você precisará usar o servidor DNS configurado pelo administrador da rede.

N1QLPort¶

A porta para conexão com o Couchbase N1QL Endpoint.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

O padrão é 8093 quando não estiver usando SSL e 18093 quando estiver usando SSL. Consulte Usar SSL.

Esta porta é usada para enviar consultas quando CouchbaseService é definido como N1QL. Quaisquer solicitações para gerenciar índices também passarão por esta porta.

AnalyticsPort¶

A porta para conexão com o Couchbase Analytics Endpoint.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

O padrão é 8095 quando não estiver usando SSL e 18095 quando estiver usando SSL. Consulte Usar SSL.

Esta porta é usada para enviar consultas quando CouchbaseService está definido como Analytics.

WebConsolePort¶

A porta para conexão com o Console da Web Couchbase.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

O padrão é 8091 quando não estiver usando SSL e 18091 quando estiver usando SSL. Consulte Usar SSL.

Essa porta é usada para operações de API, como gerenciamento de buckets.

SSL¶

Esta seção fornece uma lista completa de propriedades SSL que você pode configurar.

SSLClientCert¶

O armazenamento de certificados de cliente TLS/SSL para autenticação de cliente SSL (SSL bidirecional).

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

O nome do armazenamento de certificados para o certificado do cliente.

O SSLClientCertType campo especifica o tipo de armazenamento de certificado especificado por SSLClientCert. Se o armazenamento estiver protegido por senha, especifique a senha em SSLClientCertPassword.

SSLClientCert é usado em conjunto com o SSLClientCertSubject para especificar os certificados do cliente. Se SSLClientCert tem um valor e SSLClientCertSubject for definido, uma pesquisa por um certificado será iniciada. Consulte SSLClientCertSubject Para maiores informações.

As designações de armazenamentos de certificados dependem da plataforma.

A seguir estão as designações dos armazenamentos de certificados de Usuário e Máquina mais comuns no Windows:

Em Java, o armazenamento de certificados normalmente é um arquivo contendo certificados e chaves privadas opcionais.

Quando o tipo de armazenamento de certificado for PFXFile, essa propriedade deverá ser configurada para o nome do arquivo. Quando o tipo é PFXBlob, a propriedade deve ser configurada para o conteúdo binário de um arquivo PFX (por exemplo, armazenamento de certificados PKCS12).

SSLClientCertType¶

O tipo de armazenamento de chaves que contém o certificado do cliente TLS/SSL.

Valores Possíveis¶

USER, MACHINE, PFXFILE, PFXBLOB, JKSFILE, JKSBLOB, PEMKEY_FILE, PEMKEY_BLOB, PUBLIC_KEY_FILE, PUBLIC_KEY_BLOB, SSHPUBLIC_KEY_FILE, SSHPUBLIC_KEY_BLOB, P7BFILE, PPKFILE, XMLFILE, XMLBLOB

Tipo de Dados¶

string

Valor Padrão¶

"USER"

Observações¶

Esta propriedade pode assumir um dos seguintes valores:

SSLClientCertPassword¶

A senha para o certificado de cliente TLS/SSL.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Se o armazenamento de certificados for de um tipo que requer uma senha, essa propriedade será usada para especificar essa senha para abrir o armazenamento de certificados.

SSLClientCertSubject¶

O assunto do certificado de cliente TLS/SSL.

Tipo de Dados¶

string

Valor Padrão¶

"\*"

Observações¶

Ao carregar um certificado, o assunto é usado para localizar o certificado na loja.

Se uma correspondência exata não for encontrada, a loja é pesquisada em busca de assuntos que contenham o valor da propriedade. Se uma correspondência ainda não for encontrada, a propriedade será definida como uma string vazia e nenhum certificado será selecionado.

O valor especial "*" seleciona o primeiro certificado no armazenamento de certificados.

O assunto do certificado é uma lista separada por vírgulas de campos e valores de nomes distintos. Por exemplo, "CN=www.server.com, OU=test, C=US, E=support@company.com". Os campos comuns e seus significados são mostrados abaixo.

Se um valor de campo contiver uma vírgula, ela deverá ser colocada entre aspas.

Usar SSL¶

Se deve negociar TLS/SSL ao conectar-se ao servidor Couchbase.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

Quando definido como verdadeiro, os padrões das seguintes opções mudam:

Esta opção deve ser ativada ao conectar-se ao Couchbase Cloud porque todas as implantações do Couchbase Cloud usam SSL por padrão.

SSLServerCert¶

O certificado a ser aceito do servidor ao conectar usando TLS/SSL.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Se estiver usando uma conexão TLS/SSL, esta propriedade pode ser usada para especificar o certificado TLS/SSL a ser aceito do servidor. Qualquer outro certificado que não seja confiável para a máquina é rejeitado.

Esta propriedade pode assumir as seguintes formas:

Se não for especificado, qualquer certificado confiável pela máquina será aceito.

Os certificados são validados como confiáveis pela máquina com base no armazenamento confiável do sistema. O armazenamento confiável usado é o valor 'javax.net.ssl.trustStore' especificado para o sistema. Se nenhum valor for especificado para esta propriedade, o armazenamento confiável padrão do Java será usado (por exemplo, JAVA_HOME\lib\security\cacerts).

Use '*' para indicar a aceitação de todos os certificados. Observe que isso não é recomendado devido a questões de segurança.

Esquema¶

Esta seção fornece uma lista completa de propriedades de esquema que você pode configurar.

Localização¶

Um caminho para o diretório que contém os arquivos de esquema que definem tabelas, exibições e procedimentos armazenados.

Tipo de Dados¶

string

Valor Padrão¶

"%APPDATA%\\\Couchbase Data Provider\\Schema"

Observações¶

O caminho para um diretório que contém os arquivos de esquema para o conector (arquivos .rsd para tabelas e exibições, arquivos .rsb para procedimentos armazenados). A localização da pasta pode ser um caminho relativo a partir da localização do executável. O Location a propriedade só é necessária se você quiser personalizar definições (por exemplo, alterar um nome de coluna, ignorar uma coluna e assim por diante) ou estender o modelo de dados com novas tabelas, exibições ou procedimentos armazenados.

Se não for especificado, o local padrão é "%APPDATA%\\ Couchbase Data Provider\Schema" com %APPDATA% sendo definido para o diretório de configuração do usuário:

Esquemas Navegáveis¶

Essa propriedade restringe os esquemas relatados a um subconjunto dos esquemas disponíveis. Por exemplo, BrowsableSchemas=SchemaA,SchemaB,SchemaC.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Listar os esquemas de bancos de dados pode ser caro. Fornecer uma lista de esquemas na string de conexão melhora o desempenho.

Tabelas¶

Esta propriedade restringe as tabelas reportadas a um subconjunto das tabelas disponíveis. Por exemplo, Tabelas=TabelaA,TabelaB,TabelaC.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Listar as tabelas de alguns bancos de dados pode ser caro. Fornecer uma lista de tabelas na string de conexão melhora o desempenho do conector.

Essa propriedade também pode ser usada como uma alternativa para listar automaticamente as exibições se você já souber com quais deseja trabalhar e, caso contrário, haveria muitos para trabalhar.

Especifique as tabelas que deseja em uma lista separada por vírgulas. Cada tabela deve ser um identificador SQL válido com quaisquer caracteres especiais escapados usando colchetes, aspas duplas ou acentos graves. Por exemplo, Tables=TableA,[TableB/WithSlash],WithCatalog.WithSchema.`TableC With Space`.

Observe que, ao conectar-se a uma fonte de dados com vários esquemas ou catálogos, você precisará fornecer o nome totalmente qualificado da tabela nesta propriedade, como no último exemplo aqui, para evitar ambigüidade entre tabelas que existem em vários catálogos ou esquemas.

Visualizações¶

Restringe as visualizações relatadas a um subconjunto das tabelas disponíveis. Por exemplo, Views=ViewA,ViewB,ViewC.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Listar as exibições de alguns bancos de dados pode ser caro. Fornecer uma lista de exibições na string de conexão melhora o desempenho do conector.

Essa propriedade também pode ser usada como uma alternativa para listar automaticamente as exibições se você já souber com quais deseja trabalhar e, caso contrário, haveria muitos para trabalhar.

Especifique as exibições desejadas em uma lista separada por vírgulas. Cada exibição deve ser um identificador SQL válido com quaisquer caracteres especiais escapados usando colchetes, aspas duplas ou acentos graves. Por exemplo, Views=ViewA,[ViewB/WithSlash],WithCatalog.WithSchema.`ViewC With Space`.

Observe que, ao conectar-se a uma fonte de dados com vários esquemas ou catálogos, você precisará fornecer o nome totalmente qualificado da tabela nesta propriedade, como no último exemplo aqui, para evitar ambigüidade entre tabelas que existem em vários catálogos ou esquemas.

Dataverso¶

Qual dataverse do Analytics deve ser verificado ao descobrir tabelas.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Esta propriedade está vazia por padrão, o que significa que todos os dataverses serão verificados e os nomes das tabelas serão gerados conforme descrito em DataverseSeparator.

Se você atribuir essa propriedade a um valor não em branco, o conector verificará apenas o dataverse correspondente (por exemplo, definir isso como "Padrão" verifica o dataverse padrão). Como apenas um dataverse está sendo verificado, os nomes das tabelas não serão prefixados com o nome do dataverse. Recomenda-se definir essa propriedade como "Padrão" se você vier de uma versão anterior do conector e precisar de compatibilidade com versões anteriores.

Se você estiver se conectando ao Couchbase 7.0 ou posterior, esta opção será tratada como um nome composto contendo um conjunto de dados e um escopo. Por exemplo, se você já criou coleções como estas:

CREATE ANALYTICS SCOPE websites.exampledotcom
CREATE ANALYTICS COLLECTION websites.exampledotcom.traffic ON examplecom_traffic_bucket
CREATE ANALYTICS COLLECTION websites.exampledotcom.ads ON examplecom_ads_bucket

Você definiria essa opção como "websites.exampledotcom".

TipoDetecçãoEsquema¶

Determina como o provedor cria tabelas e colunas a partir dos depósitos encontrados no Couchbase.

Tipo de Dados¶

string

Valor Padrão¶

"DocType"

Observações¶

Uma lista separada por vírgulas das seguintes opções:

InferNumSampleValues¶

O número máximo de valores para cada campo a ser verificado antes de determinar seu tipo de dados. Aplica-se à descoberta automática de esquema quando TypeDetectionScheme é definido como INFER.

Tipo de Dados¶

string

Valor Padrão¶

"10"

Observações¶

O número máximo de valores para varredura de cada campo dos documentos de amostra antes de determinar o tipo de dados do campo. Esta propriedade permite configuração adicional de Automatic Schema Discovery quando estiver usando o comando Couchbase Infer -- TypeDetectionScheme também deve ser definido como Infer para usar esta propriedade.

InferSampleSize¶

O número máximo de documentos a serem verificados para as colunas disponíveis no depósito. Aplica-se à descoberta automática de esquema quando TypeDetectionScheme é definido como INFER.

Tipo de Dados¶

string

Valor Padrão¶

"100"

Observações¶

O número máximo de documentos a serem verificados para as colunas disponíveis no depósito. O comando Infer retornará os metadados da coluna digitalizando uma amostra aleatória de documentos do tamanho especificado aqui.

Definir um valor alto pode diminuir o desempenho. Definir um valor baixo pode impedir que a coluna e o tipo de dados sejam determinados corretamente, especialmente quando houver dados nulos.

Esta propriedade permite configuração adicional de Automatic Schema Discovery quando estiver usando o comando Couchbase Infer -- TypeDetectionScheme também deve ser definido como Infer para usar esta propriedade.

InferSimilarityMetric¶

Especifica o grau de similaridade em que esquemas diferentes serão considerados o mesmo sabor. Aplica-se à descoberta automática de esquema quando TypeDetectionScheme é definido como INFER.

Tipo de Dados¶

string

Valor Padrão¶

"0.7"

Observações¶

Essa propriedade especifica o quão semelhantes dois esquemas devem ser para serem considerados o mesmo tipo. Como exemplo, considere as seguintes linhas:

Row 1: ColA, ColB, ColC, ColD
Row 2: ColA, ColB, ColE, ColF
Row 3: ColB, ColF, ColX, ColY

Você pode configurar as colunas retornadas para cada sabor com diferentes InferSimilarityMetric valores, conforme exemplos a seguir:

• Se você definir InferSimilarityMetric para 1, o conector não retornará nenhum tipo.
• Se você definir InferSimilarityMetric para 0,5, o conector retornará 2 tipos, Row1 e Row2 constituindo um, e Row3 constituindo outro.
• Se você definir InferSimilarityMetric para 0,25, o conector retornará um único sabor contendo todas as linhas.

Você pode então consultar os tipos de documento usando a notação de ponto, como na seguinte declaração:

SELECT * FROM [Items.Technology]

Esta propriedade permite configuração adicional de Automatic Schema Discovery quando estiver usando o comando Couchbase Infer -- TypeDetectionScheme também deve ser definido como Infer para usar esta propriedade.

Esquemas Flexíveis¶

Se o provedor permite que as consultas usem colunas que não foram descobertas.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

Por padrão, o conector só permitirá que as consultas usem colunas encontradas durante o processo de descoberta de metadados (consulte TypeDetectionScheme para detalhes). Isso significa que o conector possui as informações completas para cada coluna que apresenta, mas também significa que os campos definidos em apenas alguns documentos podem não ser expostos. Desativar esta opção significa que o conector permitirá que você escreva uma consultar com as colunas que desejar. Se você usar colunas em uma consultar que não foram descobertas, o conector assumirá que são cadeias de caracteres simples.

Por exemplo, o conector usa informações de tipo de coluna para converter datas automaticamente para comparação, já que o Couchbase não pode comparar datas diretamente de forma nativa. Se o conector detectar que datecol é um campo de data, ele poderá aplicar a conversão STR_TO_MILLIS automaticamente:

/* SQL */
WHERE datecol < '2020-06-12';

/* N1QL */
WHERE STR_TO_MILLIS(datecol) < STR_TO_MILLIS('2020-06-12');

Ao usar colunas não descobertas, o conector não pode fazer esse tipo de conversão para você. Você deve aplicar as conversões necessárias manualmente para garantir que as operações se comportem da maneira que você deseja.

ExposeTTL¶

Especifica se as informações TTL do documento devem ser expostas.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

Por padrão, o conector não expõe valores TTL nem considera TTLs de documento ao executar operações DML. Habilitar esta opção expõe os valores TTL de duas maneiras:

• Todas as tabelas recebem uma nova coluna chamada Document.Expiration que contém o valor TTL para cada documento. Esta coluna é um número inteiro e retorna qualquer valor TTL armazenado diretamente no Couchbase. Esta coluna é de leitura/gravação em tabelas de bucket e somente leitura em tabelas filhas.
• INSERT e UPDATE usarão este campo para definir valores TTL ou para preservá-los (para atualização) quando nenhum for fornecido. Definir o campo como 0 ou NULL removerá o TTL de todos os documentos afetados.

Observe que habilitar esses recursos requer que seu servidor seja versão 6.5.1 ou posterior e que seu CouchbaseService é definido como N1QL. Se algum desses não for o caso, o conector não se conectará.

Sequências Numéricas¶

Se os valores de string devem ser tratados como números.

Tipo de Dados¶

bool

Valor Padrão¶

true

Observações¶

Por padrão, essa propriedade está habilitada e o conector tratará os valores de cadeia de caracteres como numéricos se todos os valores de amostra durante a detecção de esquema forem numéricos. Isso pode causar erros de digitação posteriormente se o campo contiver valores não numéricos em outros documentos. Se esta propriedade estiver desativada, as strings numéricas serão deixadas como strings, embora outros tipos de dados baseados em string, como timestamps, ainda sejam detectados.

Por exemplo, o campo "código" no intervalo abaixo seria afetado por essa configuração. Por padrão, seria considerado um número inteiro, mas se essa propriedade fosse habilitada, seria tratada como uma string.

{ "code": "123", "message": "Please restart your computer" }
{ "code": "456", "message": "Urgent update must be applied" }

IgnoreChildAggregates¶

Se o provedor expõe colunas agregadas que também estão disponíveis como tabelas filhas. Ignorado se TableSupport não estiver definido como Full.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

O conector exporá os campos de matriz dentro de um bucket como uma tabela filha separada, como no exemplo Games_scores descrito em Automatic Schema Discovery. Por padrão, o conector também exporá esses campos de matriz como agregados JSON na tabela base. Por exemplo, qualquer uma dessas consultas retornaria informações sobre pontuações de jogos:

/* Return each score as an individual row */
SELECT value FROM Games_scores;

/* Return all scores for each Game as a JSON string */
SELECT scores FROM Games;

Como esses agregados estão expostos na tabela base, eles serão gerados mesmo quando as informações que eles contêm forem redundantes. Por exemplo, ao executar esta união, o agregado de pontuações em Games é preenchido, bem como a coluna de valor em Games_scores. Internamente, isso faz com que duas cópias dos dados das partituras sejam transferidas do Couchbase.

/* Retrieves score data twice, once for Games.scores and once for Games_scores.value */
SELECT * FROM Games INNER JOIN Games_scores ON Games.[Document.Id] = Games_scores.[Document.Id]

Esta opção pode ser usada para evitar que o campo agregado seja exposto quando as mesmas informações também estiverem disponíveis em uma tabela filha. No exemplo dos jogos, definir essa opção como true significa que a tabela Games exporia apenas uma coluna de chave primária. A única maneira de recuperar informações sobre pontuações seria a tabela filha, portanto, os dados de pontuação seriam lidos apenas uma vez no Couchbase.

/* Only exposes Document.Id, not scores */
SELECT * FROM Games;

/* Only retrieves score data once for Games_scores.value */
SELECT * FROM Games INNER JOIN Games_scores ON Games.[Document.Id] = Games_scores.[Document.Id]

Observe que esta opção substitui FlattenArrays, já que todos os dados de arrays nivelados também estão disponíveis como tabelas filhas. Se esta opção for definida, nenhum nivelamento de matriz será executado, mesmo se FlattenArrays é definido como um valor acima de 0.

TableSuporte¶

Quanto esforço o provedor colocará na descoberta de tabelas no servidor Couchbase.

Valores Possíveis¶

Full, Basic, None

Tipo de Dados¶

string

Valor Padrão¶

"Full"

Observações¶

As opções disponíveis são:

NewChildJoinsMode¶

Determina o tipo de modelo de tabela filho que o provedor expõe.

Tipo de Dados¶

string

Valor Padrão¶

"false"

Observações¶

Por padrão, o conector expõe um modelo de dados compatível com versões anteriores que não é totalmente relacional. Neste modo, as tabelas não filhas têm uma chave primária chamada Document.Id, mas as tabelas filhas não possuem uma chave primária. Em vez disso, eles têm uma coluna chamada Document.Id que tem o mesmo valor que o Document.Id da linha pai que contém a linha filho.

Por exemplo, uma tabela pai invoices contendo registros de fatura pode ter esta aparência:

E seu filho invoices_lineitems contendo itens de linha pode ter esta aparência:

Este modelo tem várias limitações:

• Resultados complexos de JOIN podem estar incorretos. Na maioria dos casos, o conector pode traduzir um JOIN como SELECT * FROM invoices INNERT JOIN invoices_lineitems ON invoices.[Document.Id] = invoices_lineitems.[Document.Id] em um UNNEST. Mas se o JOIN for muito complexo, ambos os lados serão executados separadamente, o que pode produzir resultados incorretos.
• As operações DML em tabelas filho aninhadas são impossíveis porque não há como especificar qual linha do filho do meio usar. Por exemplo, você não pode alterar as linhas em uma tabela como invoices_lineitems_discounts pois não há como especificar a linha que contém o desconto que você está atualizando.
• Alguns ambientes como o SSIS podem não ser capazes de operar em tabelas filhas porque não possuem chaves primárias.

O modelo de dados NewChildJoins é totalmente relacional. Neste modo, as tabelas não filhas têm o mesmo Document.Id como antes, mas as tabelas filhas são estendidas para ter uma chave estrangeira e uma chave primária. A chave estrangeira é chamada Document.Parent e refere-se ao Document.Id da linha na tabela pai que contém a linha filha. A chave primária é chamada Document.Id e contém um caminho que se refere exclusivamente a essa linha filha.

Por exemplo, as mesmas tabelas acima ficariam assim no modelo NewChildJoins. invoices seria o mesmo:

No entanto, invoices_lineitems teria uma chave primária e estrangeira. A chave primária contém o ID da linha pai, bem como a posição da linha filha na linha pai.

Isso corrige as limitações do antigo modelo de dados:

• Os resultados JOIN complexos são sempre consistentes porque vinculam chaves estrangeiras a chaves primárias. SELECT * FROM invoices INNERT JOIN invoices_lineitems ON invoices.[Document.Id] = invoices_lineitems.[Document.Parent]
• Operações DML em tabelas filhas aninhadas são permitidas porque o Document.Id contém todas as informações necessárias para selecionar linhas específicas, independentemente da profundidade da tabela.
• Ambientes que dependem de chaves primárias podem utilizar essas tabelas e gerar consultas JOIN desde as relações entre Document.Id e Document.Parent as colunas estão incluídas nos metadados do conector.

Diversos¶

Esta seção fornece uma lista completa de diversas propriedades que você pode configurar.

AllowJSONParameters¶

Permite que JSON bruto seja usado em parâmetros quando QueryPassthrough está ativado.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

Esta opção afeta como os parâmetros de string são tratados ao usar consultas N1QL e SQL++ diretas por meio de QueryPassthrough. Por exemplo, considere esta consultar:

INSERT INTO `balde` (KEY, VALUE) VALUES ("1", @x)

Por padrão, essa opção está desativada e os parâmetros de string são citados e escapados em strings JSON. Isso significa que qualquer valor pode ser usado com segurança como um parâmetro de string, mas também significa que os parâmetros não podem ser usados como documentos JSON brutos:

/*
 * If @x is set to: test value " contains quote
 *
 * Result is a valid query
*/
INSERT INTO `balde` (KEY, VALUE) VALUES ("1", "test value \" contains quote")

/*
 * If @x is set to: {"a": ["valid", "JSON", "value"]}
 *
 * Result contains string instead of JSON document
*/
INSERT INTO `balde` (KEY, VALUE) VALUES ("1", "{\"a\": [\"valid\", \"JSON\", \"value\"]})

Quando esta opção está habilitada, os parâmetros de string são considerados JSON válidos. Isso significa que documentos JSON brutos podem ser usados como parâmetros, mas também significa que todas as strings simples devem ter escape:

/*
 * If @x is set to: test value " contains quote
 *
 * Result is an invalid query
*/
INSERT INTO `balde` (KEY, VALUE) VALUES ("1", test value " contains quote)

/*
 * If @x is set to: {"a": ["valid", "JSON", "value"]}
 *
 * Result is a JSON document
*/
INSERT INTO `balde` (KEY, VALUE) VALUES ("1", {"a": ["valid", "JSON", "value"]})

Consulte ValidateJSONParameters para obter mais detalhes sobre como os parâmetros são validados quando esta opção está habilitada.

ChildSeparator¶

O caractere ou caracteres usados para denotar tabelas filhas.

Tipo de Dados¶

string

Valor Padrão¶

"\_"

Observações¶

Ao criar uma tabela filho para um array abaixo de um bucket, o conector gerará o nome da tabela filho concatenando o nome da tabela base, juntamente com esse separador e cada elemento de caminho.

Por exemplo, se este documento estiver no bloco "clientes", a tabela filho para o campo de endereços será chamada de "endereços_clientes".

{
  "addresses": [
    {"street": "123 Main St"},
    {"street": "424 Pleasant Ct"},
    {"street": "719 Blue Way"}
  ]
}

CreateTableRamQuota¶

A cota de RAM padrão, em megabytes, a ser usada ao inserir depósitos por meio da sintaxe CREATE TABLE.

Tipo de Dados¶

string

Valor Padrão¶

"250"

Observações¶

A cota de RAM padrão, em megabytes, a ser usada ao inserir depósitos por meio da sintaxe CREATE TABLE.

DataverseSeparator¶

O caractere ou caracteres usados para denotar dataverses e escopos/coleções do Analytics.

Tipo de Dados¶

string

Valor Padrão¶

"."

Observações¶

Ao usar o serviço Analytics, o conector varrerá todos os conjuntos de dados de todos os bancos de dados disponíveis. Para evitar possíveis conflitos de nomes, ele incluirá o nome do dataverse e o nome do dataset no nome da tabela gerada.

Por padrão, isso é definido como ".", de modo que, se houver um conjunto de dados chamado "users" no dataverse "Default", a tabela gerada será "Default.users".

Essa propriedade também é usada ao gerar nomes de tabela para coleções (no N1QL e no Analytics) no Couchbase 7 e posterior. Por exemplo, um bucket chamado "users" que tem duas coleções chamadas "active" e "inactive" sob o escopo "status" seria detectado como as tabelas "users.status.active" e "users.status.inactive".

FlattenArrays¶

O número de elementos a serem expostos como colunas de matrizes aninhadas. Ignorado se IgnoreChildAggregates estiver ativado.

Tipo de Dados¶

string

Valor Padrão¶

"0"

Observações¶

Por padrão, arrays aninhados são retornados como strings de JSON. O FlattenArrays propriedade pode ser usada para nivelar os elementos de arrays aninhados em colunas próprias. Isso é recomendado apenas para arrays que devem ser curtos.

Definir FlattenArrays para o número de elementos que você deseja retornar de arrays aninhados. Os elementos especificados são retornados como colunas. O índice baseado em zero é concatenado ao nome da coluna. Outros elementos são ignorados.

Por exemplo, você pode retornar um número arbitrário de elementos de um array de strings:

["FLOW-MATIC","LISP","COBOL"]

Quando FlattenArrays é definido como 1, a matriz anterior é simplificada na tabela a seguir:

Flatten Objects¶

Defina FlattenObjects como true para nivelar as propriedades do objeto em colunas próprias. Caso contrário, os objetos aninhados em arrays são retornados como strings de JSON.

Tipo de Dados¶

bool

Valor Padrão¶

true

Observações¶

Definir FlattenObjects para true para achatar as propriedades do objeto em colunas próprias. Caso contrário, os objetos aninhados em arrays são retornados como strings de JSON. O nome da propriedade é concatenado no nome do objeto com um sublinhado para gerar o nome da coluna.

Por exemplo, você pode nivelar os objetos aninhados abaixo no momento da conexão:

address : {
  "street" : "123 Main St.",
  "city"   : "Nowhere",
  "state"  : "NY",
  "zip"    : "12345"
}

Quando FlattenObjects é definido como true, o objeto anterior é simplificado na tabela a seguir:

Sabor Separador¶

O caractere ou caracteres usados para denotar sabores.

Tipo de Dados¶

string

Valor Padrão¶

"."

Observações¶

Quando o conector detecta uma tabela com sabor, usando um DocType ou Infer TypeDetectionScheme, ele nomeia tabelas com variações concatenando o nome do depósito subjacente, este separador e o valor da variação principal do depósito.

Por exemplo, se o conector detectar o sabor "docType = 'beer'" no balde "beer-sample", ele gerará a tabela "beer-sample.beer" que contém apenas documentos em "beer-sample" que têm o tipo de documento "cerveja".

GenerateSchemaFiles¶

Indica a preferência do usuário quanto a quando os esquemas devem ser gerados e salvos.

Valores Possíveis¶

Never, OnUse, OnStart, OnCreate

Tipo de Dados¶

string

Valor Padrão¶

"Never"

Observações¶

GenerateSchemaFiles permite que você salve as definições de tabela identificadas por Automatic Schema Discovery. Esta propriedade gera esquemas para arquivos .rsd no caminho especificado por Location.

As configurações disponíveis são as seguintes:

• Nunca: Um arquivo de esquema nunca será gerado.
• OnUse: Um arquivo de esquema será gerado na primeira vez que uma tabela for referenciada, desde que o arquivo de esquema para a tabela ainda não exista.
• OnStart: Um arquivo de esquema será gerado no momento da conexão para todas as tabelas que atualmente não possuem um arquivo de esquema.
• OnCreate: Um arquivo de esquema será gerado ao executar uma consultar SQL CREATE TABLE.

Observe que, se você deseja gerar novamente um arquivo, primeiro precisará excluí-lo.

Gerar Esquemas com SQL¶

Ao definir GenerateSchemaFiles para OnUse, o conector gera esquemas conforme você executa consultas SELECT. Os esquemas são gerados para cada tabela referenciada na consultar.

Ao definir GenerateSchemaFiles para OnCreate, os esquemas são gerados apenas quando uma consultar CREATE TABLE é executada.

Gerar Esquemas na Conexão¶

Outra maneira de usar essa propriedade é obter esquemas para cada tabela em seu banco de dados quando você se conectar. Para isso, defina GenerateSchemaFiles para OnStart e conecte.

Alternativas aos Esquemas Estáticos¶

Se suas estruturas de dados forem voláteis, considere definir GenerateSchemaFiles para Nunca e usando esquemas dinâmicos. Consulte Descoberta automática de esquema para obter mais informações sobre esquemas dinâmicos.

Esquemas de Edição¶

Os arquivos de esquema têm um formato simples que os torna fáceis de modificar. Consulte Definições de esquema personalizado Para maiores informações.

InserirValoresNulos¶

Determina se um INSERT deve incluir campos com valores NULL.

Tipo de Dados¶

bool

Valor Padrão¶

true

Observações¶

Por padrão, o conector usa valores NULL fornecidos em uma instrução INSERT e os insere como valores nulos JSON.

Se esta opção estiver desativada, os valores SQL NULL serão ignorados durante um INSERT. No caso de colunas de array (FlattenArrays deve ser definido para recuperá-los), isso significa que os índices de matriz são deslocados para compensar os valores que foram removidos.

MaxRows¶

Limita o número de linhas retornadas quando nenhuma agregação ou agrupamento é usado na consultar. Isso ajuda a evitar problemas de desempenho em tempo de design.

Tipo de Dados¶

int

Valor Padrão¶

-1

Observações¶

Limita o número de linhas retornadas quando nenhuma agregação ou agrupamento é usado na consultar. Isso ajuda a evitar problemas de desempenho em tempo de design.

Outro¶

Essas propriedades ocultas são usadas apenas em casos de uso específicos.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

As propriedades listadas abaixo estão disponíveis para casos de uso específicos. Os casos de uso e a funcionalidade normais do driver não devem exigir essas propriedades.

Especifique várias propriedades em uma lista separada por ponto e vírgula.

Integração e Formatação¶

Tamanho da Página¶

O número máximo de resultados a serem retornados por página do Couchbase.

Tipo de Dados¶

int

Valor Padrão¶

1000

Observações¶

O Pagesize a propriedade afeta o número máximo de resultados a serem retornados por página do Couchbase. Definir um valor mais alto pode resultar em melhor desempenho ao custo de memória adicional alocada por página consumida.

PeriodsSeparator¶

O caractere ou caracteres usados para denotar hierarquia.

Tipo de Dados¶

string

Valor Padrão¶

"."

Observações¶

Ao nivelar objetos e matrizes, o conector usará esse valor para separar diferentes níveis de objetos e matrizes. Por exemplo, se seu servidor Couchbase retornar um documento como este (e FlattenObjects estiver ativado), o conector retornará as colunas "geo.latitude" e "geo.longitude" se o separador de períodos estiver definido como ".".

{
  "geo": {
    "latitude": 35.9132,
    "longitude": -79.0558
  }
}

Pseudocolunas¶

Esta propriedade indica se deve ou não incluir pseudocolunas como colunas na tabela.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Essa configuração é particularmente útil no Entity Framework, que não permite definir um valor para uma pseudocoluna, a menos que seja uma coluna de tabela. O valor dessa configuração de conexão está no formato "Table1=Column1, Table1=Column2, Table2=Column3". Você pode usar o caractere "*" para incluir todas as tabelas e todas as colunas; por exemplo, "*=*".

QueryExecutionTimeout¶

Isso define o tempo limite do lado do servidor para a consultar, que controla por quanto tempo o Couchbase executará a consultar antes de retornar um erro de tempo limite.

Tipo de Dados¶

string

Valor Padrão¶

"-1"

Observações¶

O padrão é -1, que desativa o tempo limite. Ao habilitar o timeout, o valor deve incluir uma quantidade e uma unidade, que pode ser: "ns" (nanossegundos), "us" (microssegundos), "ms" (milissegundos), "s" (segundos), "m" (minutos) ou "h" (horas). Por exemplo, "5m" e "300s" definem tempos limite de 5 minutos.

Há um tempo limite do lado do servidor também chamado de "tempo limite de varredura de índice", que substituirá este se for menor. Por padrão, o tempo limite de varredura do índice é de 2 minutos, mas pode ser alterado configurando a propriedade "indexer.settings.scan_timeout" em seu servidor Couchbase.

QueryPassthrough¶

Esta opção passa a consultar para o servidor Couchbase como está.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

Quando isso é definido, as consultas são passadas diretamente para o Couchbase.

RowScanDepth¶

O número máximo de linhas a serem verificadas para procurar as colunas disponíveis em uma tabela.

Tipo de Dados¶

int

Valor Padrão¶

100

Observações¶

As colunas em uma tabela devem ser determinadas pela varredura das linhas da tabela. Esse valor determina o número máximo de linhas que serão verificadas.

Definir um valor alto pode diminuir o desempenho. Definir um valor baixo pode impedir que o tipo de dados seja determinado corretamente, especialmente quando houver dados nulos.

Comparação Estrita¶

Ajusta com que precisão converter filtros em consultas de entrada SQL em consultas Couchbase. Isso pode ser definido como uma lista de valores separados por vírgula, onde cada valor pode ser um dos seguintes: data, número, booleano ou string.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Esta opção está vazia por padrão, o que significa que as cláusulas WHERE enviadas para o Couchbase incluirão funções extras que convertem valores para que mais comparações funcionem.

Por exemplo, deixar a configuração "string" fora da lista faz com que os arrays sejam convertidos, para que possam ser comparados com strings:

SELECT * FROM Bucket WHERE MyArrayColumn = '[1,2,3]'

Se definido como um valor, as consultas incluindo os tipos relevantes de comparações serão traduzidas literalmente. Isso faz melhor uso dos índices do Couchbase, mas significa que os tipos de comparações devem estar em um formato que o Couchbase possa comparar diretamente.

Por exemplo, se "data" for fornecida como uma das opções, as datas devem corresponder ao formato em que são armazenadas no Couchbase, pois não serão convertidas automaticamente:

SELECT * FROM Bucket WHERE MyDateColumn = '2018-10-31T10:00:00';

Tempo Esgotado¶

O valor em segundos até que o erro de timeout seja lançado, cancelando a operação.

Tipo de Dados¶

int

Valor Padrão¶

60

Observações¶

Se Timeout = 0, as operações não expiram. As operações são executadas até serem concluídas com êxito ou até encontrarem uma condição de erro.

Se Timeout expira e a operação ainda não está concluída, o conector lança uma exceção.

Durabilidade da Transação¶

Especifica como um documento deve ser armazenado para que uma transação seja bem-sucedida. Especifica se deve usar transações N1QL ao executar consultas.

Valores Possíveis¶

None, Majority, MajorityAndPersistActive, PersistToMajority

Tipo de Dados¶

string

Valor Padrão¶

"Majority"

Observações¶

Se UsarTransações estiver ativado, essa opção poderá ser definida para determinar quando o Couchbase permitirá gravações em transações para confirmação. A documentação do Couchbase sobre Durabilidade e Transações contém todos os detalhes, abaixo está um resumo de alto nível.

Esta opção controla os requisitos em quorum e persistence. O quorum pode exigir nenhuma réplica de bucket para receber o documento (Nenhuma) ou uma maioria de réplicas para ter o documento (todas as outras). O nível de persistência requer que o documento seja armazenado na memória de réplica (Majoriy) ou no disco de réplica (MajorityAndPersistActive, PersistToMajority).

None só é útil se o bucket que você está usando não estiver configurado para réplicas. As outras opções podem ser usadas dependendo das compensações necessárias de desempenho e durabilidade. Persistir em mais réplicas é mais lento, mas oferece maior resiliência contra a falha de um nó.

TransactionTimeout¶

Isso define a quantidade de tempo que uma transação pode ser executada antes de atingir o tempo limite do Couchbase.

Tipo de Dados¶

string

Valor Padrão¶

""

Observações¶

Se as transações estiverem habilitadas, o conector assumirá como padrão a configuração de tempo limite de transação padrão do servidor.

Ao habilitar o timeout, o valor deve incluir uma quantidade e uma unidade, que pode ser: "ns" (nanossegundos), "us" (microssegundos), "ms" (milissegundos), "s" (segundos), "m" (minutos) ou "h" (horas). Por exemplo, "5m" e "300s" definem tempos limite de 5 minutos.

Há também tempos limite de transação no nível do cluster e no nível do nó que substituem este se forem menores. Por exemplo, se o tempo limite no nível do nó for definido como um minuto, definir essa opção como "5m" não terá efeito.

UpdateNullValues¶

Determina se um UPDATE grava valores NULL como NULL ou os remove.

Tipo de Dados¶

bool

Valor Padrão¶

true

Observações¶

Por padrão, o conector usará valores NULL fornecidos em uma instrução UPDATE e definirá o campo no Couchbase como NULL.

Se esta opção estiver desativada, os valores SQL NULL em um UPDATE farão com que o conector marque o campo como MISSING. Isso remove o campo do objeto que o contém ou, se o campo estiver contido em uma matriz (por FlattenArrays) então esse elemento é definido como NULL.

Essa opção deve ser usada com cuidado, pois o conector pode não detectar que o campo existe se ele for removido de documentos suficientes em um depósito.

UseCollectionsForDDL¶

Se deve assumir que as instruções CREATE TABLE usam coleções em vez de tipos. Só entra em vigor ao conectar-se ao Couchbase v7+ e GenerateSchemaFiles é definido como OnCreate.

Tipo de Dados¶

bool

Valor Padrão¶

false

Observações¶

Normalmente, o conector assumirá que os nomes de tabelas compostas referenciados em uma instrução CREATE TABLE são tipos. Para compatibilidade, este ainda é o padrão com o Couchbase v7+, embora os sabores não sejam recomendados lá.

CREATE TABLE [myBucket.myFlavor](
  [ID do documento] VARCHAR PRIMARY KEY,
  docType VARCHAR,
  sometext VARCHAR,
  somenum INT
)

Ative esta opção para assumir que as instruções CREATE TABLE referem-se à coleção. Nesse cenário, essa consultar criará o bucket e o escopo, se necessário, antes de criar a coleção e definir um índice primário:

CREATE TABLE [myBucket.myScope.myCollection](
  [ID do documento] VARCHAR PRIMARY KEY,
  sometext VARCHAR,
  somenum INT
)

UsarTransações¶

Especifica se deve usar transações N1QL ao executar consultas.

Valores Possíveis¶

Never, Always, Explicit

Tipo de Dados¶

string

Valor Padrão¶

"Never"

Observações¶

Por padrão, o conector não usa transações para compatibilidade com versões mais antigas do Couchbase. Todas as outras opções requerem uma conexão com o Couchbase 7 ou superior. O serviço N1QL também deve ser ativado usando CouchbaseService.

Configurando para Always significa que todas as consultas usarão transações. Uma transação explícita pode ser criada na conexão e as consultas usarão essa transação enquanto ela estiver ativa. Se não houver transação explícita, as consultas usarão transações implícitas.

Definindo isso como Explicit habilita o suporte apenas para transações explícitas. Transações explícitas podem ser criadas, mas se uma não estiver ativa no momento, as instruções não criarão uma transação implícita.

Validar Parâmetros JSON¶

Permite que o provedor valide se os parâmetros de string são JSON válidos antes de enviar a consultar ao Couchbase.

Tipo de Dados¶

bool

Valor Padrão¶

true

Observações¶

Quando AllowJSONParameters e QueryPassthrough estiverem ativados, os parâmetros de consultar fornecidos ao conector serão tratados como documentos JSON brutos em vez de valores de string arbitrários. Esta opção controla o que acontece quando um JSON inválido é fornecido ao conector neste modo.

Quando essa opção estiver habilitada, o conector verificará se todos os parâmetros de string podem ser analisados como JSON válido. Se algum não puder ser, um erro será gerado e a consultar não será executada.

Quando esta opção está desativada, nenhuma verificação é executada e todos os valores de parâmetro de string são substituídos diretamente na consultar. Isso torna a execução de instruções preparadas mais rápida, mas menos segura, pois N1QL ou SQL++ inválidos podem ser enviados para o Couchbase.