Novidades na versão 0.11 e anterior
Notas de versão e informações sobre todas as atualizações e aprimoramentos no Construtor de API de Dados versão 0.11 e anterior.
Novidades na versão 0.11
Notas de versão e informações sobre as atualizações e aprimoramentos no Construtor de API de Dados versão 0.10.
Suporte do GraphQL para SQL Data Warehouse
O SQL Data Warehouse agora dá suporte a pontos de extremidade do GraphQL.
Filtragem aprimorada do Azure Cosmos DB for NoSQL
O Azure Cosmos DB for NoSQL agora tem suporte para filtros aninhados, variáveis de ID e pesquisas de matriz de cadeia de caracteres com o contains
operador .
Habilitar a coleta de dados de aplicativo com interface de linha de comando
Agora você pode usar a CLI (interface de linha de comando) do DAB para habilitar a coleta de dados com o Application Insights.
Novidades na versão 0.10
Notas de versão e informações sobre as atualizações e aprimoramentos no Construtor de API de Dados versão 0.10.
Nosso foco muda para a estabilidade à medida que nos aproximamos da Disponibilidade Geral. Embora nem todos os esforços na qualidade do código e na estabilidade do mecanismo sejam detalhados neste artigo, esta lista destaca atualizações significativas.
Notas sobre a versão do GitHub
Examine estas páginas de versão para obter uma lista abrangente de todas as alterações e melhorias:
- 2024-02-06 – Versão 0.10.23
- 2024-01-31 – Versão 0.10.21
- 2023-12-07 – Versão 0.10.11
cache na memória
A versão 0.10 apresenta o cache na memória para pontos de extremidade REST e GraphQL. Esse recurso, projetado para cache interno, estabelece as bases para o cache distribuído futuro. O cache na memória reduz a carga do banco de dados de consultas repetitivas.
Cenários de cache
- Redução da carga do banco de dados: o cache armazena resultados de consultas caras, eliminando a necessidade de chamadas de banco de dados repetidas.
- Melhorando a escalabilidade da API: o cache dá suporte a chamadas de API mais frequentes sem aumentar as solicitações de banco de dados, dimensionando significativamente os recursos da API.
Alterações de configuração
As configurações de cache estão disponíveis na runtime
seção e para cada entidade, oferecendo controle granular.
Configurações de runtime:
{
"runtime": {
"cache": {
"enabled": true,
"ttl-seconds": 6
}
}
}
- O cache está desabilitado por padrão.
- O TTL (vida útil) padrão é de 5 segundos.
Configurações de entidade:
{
"Book": {
"source": {
"object": "books",
"type": "table"
},
"graphql": {
"enabled": true,
"type": {
"singular": "book",
"plural": "books"
}
},
"rest": {
"enabled": true
},
"permissions": [
{
"role": "anonymous",
"actions": [
{
"action": "*"
}
]
}
],
"cache": {
"enabled": true,
"ttl-seconds": 6
}
}
}
Validação de configuração na CLI
A CLI agora dá suporte dab validate
à verificação de arquivos de configuração quanto a erros ou inconsistências, aprimorando o fluxo de trabalho de desenvolvimento.
Etapas de validação
- Validação de esquema
- Validação de propriedades de configuração
- Validação da permissão de configuração
- Validação de conexão de banco de dados
- Validação de metadados de entidades
Recursos de visualização
Novidades na versão 0.9
Aqui estão os detalhes sobre as alterações e a melhoria mais relevantes no Construtor de API de Dados 0.9.
Notas sobre a versão do GitHub
Examine estas páginas de versão para obter uma lista abrangente de todas as alterações e melhorias:
Habilitar o Application Insights ao hospedar automaticamente o DAB
Os logs agora podem ser transmitidos para o Application Insights para uma melhor experiência de monitoramento e depuração, especialmente quando o Construtor de API de Dados é implantado no Azure. Uma nova telemetry
seção pode ser adicionada ao arquivo de configuração para habilitar e configurar a integração com o Application Insights:
"telemetry": {
"application-insights": {
"enabled": true, // To enable/disable application insights telemetry
"connection-string": "{APP_INSIGHTS_CONNECTION_STRING}" // Application Insights connection string to send telemetry
}
}
Leia todos os detalhes na página Usar documentação do Application Insights .
Suporte para ignorar campos desnecessários no corpo da solicitação REST
Com a nova request-body-strict
opção, agora você pode decidir se ter um campo extra na carga REST gera um erro (comportamento padrão, compatível com versões anteriores) ou se os campos extras são ignorados silenciosamente.
"runtime": {
"rest": {
"enabled": true,
"path": "/api",
"request-body-strict": true
},
...
}
Ao definir a opção request-body-strict
false
como , os campos que não têm um mapeamento para o objeto de banco de dados relacionado são ignorados sem gerar nenhum erro.
Adicionando o Nome do Aplicativo para mssql
conexões
O Construtor de API de Dados agora injeta na cadeia de conexão, somente para mssql
tipos de banco de dados, o valor dab-<version>
como a Application Name
propriedade , facilitando a identificação das conexões no servidor de banco de dados. Se Application Name
já estiver presente na cadeia de conexão, a versão do Construtor de API de Dados será acrescentada a ela.
Tipo de dados de suporte time
no mssql
time
O tipo de dados agora tem suporte em mssql
bancos de dados.
Mutações na tabela com gatilhos para mssql
As mutações agora têm suporte total em tabelas com gatilhos para mssql
bancos de dados.
Impedindo a atualização/inserção de campos somente leitura em uma tabela por usuário
Detecte automaticamente os campos somente leitura do banco de dados e impeça a atualização/inserção desses campos por usuário.
Novidades na versão 0.8
Aqui estão os detalhes sobre as alterações e o aprimoramento mais relevantes no Construtor de API de Dados 0.8.
Notas sobre a versão do GitHub
Examine estas páginas de versão para obter uma lista abrangente de todas as alterações e melhorias:
- 0.8.52: página de lançamento do GitHub
- 0.8.51: página de lançamento do GitHub
- 0.8.50: página de lançamento do GitHub
- 0.8.49: página de lançamento do GitHub
Adicionado suporte para o arquivo .env
As variáveis de ambiente protegem segredos da exposição de texto sem formatação e permitem a troca de valor em configurações diferentes. No entanto, essas variáveis devem ser definidas no escopo do usuário ou do computador, o que pode levar à variável entre projetos "bleeding" se os nomes de variáveis forem duplicados. A melhor alternativa são os arquivos de ambiente. Para obter mais informações, consulte arquivos de ambiente no Construtor de API de Dados – blog.
Novidades na versão 0.7.6
Este artigo descreve as notas sobre a versão 0.7.6.
Solicitações de pull do GitHub
- Solucionar problema de negação de acesso de filtro para o Cosmos
- Correção de bug para autenticação de campo do Azure Cosmos DB quando graphql é "true", include é "*"
Suporte inicial para criação de documento de descrição do OpenAPI v3-0-1
O Construtor de API de Dados dá suporte ao padrão OpenAPI para gerar e expor documentos de descrição que contêm informações úteis sobre o serviço. Esses documentos são criados com base no arquivo de configuração de runtime e nos metadados de cada objeto de banco de dados. Esses objetos são associados a uma entidade habilitada para REST definida nesse mesmo arquivo de configuração. Em seguida, eles são expostos por meio de uma interface do usuário e disponibilizados como um arquivo serializado.
Para obter mais informações sobre as especificidades do OpenAPI e do Construtor de API de Dados, consulte OpenAPI.
Permitindo a fusão de arquivos de configuração
Adiciona a capacidade de mesclar automaticamente dois arquivos de configuração.
É possível manter vários pares de arquivos de configuração específicos de linha de base e ambiente para simplificar o gerenciamento das configurações específicas do ambiente. Por exemplo, é possível manter configurações separadas para Desenvolvimento e Produção. Esta etapa envolve ter um arquivo de configuração base que tenha todas as configurações comuns entre os diferentes ambientes. Em seguida, definindo a DAB_ENVIRONMENT
variável, é possível controlar quais arquivos de configuração serão mesclados para consumo pelo Construtor de API de Dados.
Para obter mais informações, consulte Referência da CLI.
Executando mutações GraphQL e REST em uma transação
O Construtor de API de Dados cria transações de banco de dados para executar determinados tipos de solicitações REST e GraphQL.
Há muitas solicitações, que envolvem a realização de mais de uma consulta de banco de dados. Por exemplo, para retornar os resultados de uma atualização, primeiro uma consulta para a atualização deve ser feita e, em seguida, os novos valores devem ser lidos antes de serem retornados. Quando uma solicitação requer que várias consultas de banco de dados sejam executadas, o Construtor de API de Dados agora executa essas consultas de banco de dados em uma única transação.
Você pode ler mais sobre essa funcionalidade no contexto do REST na documentação REST e do GraphQL na documentação do GraphQL.
Novidades na versão 0.6.14
Este artigo descreve o patch da versão de março de 2023 para o Construtor de API de Dados para Bancos de Dados do Azure.
Correções de bugs
- Resolver o problema de acesso negado ao filtro de consulta para o Cosmos.
- Atualmente, o Cosmos DB não dá suporte à autorização em nível de campo, para evitar a situação em que os usuários passam acidentalmente as
field
permissões na configuração de runtime, adicionamos uma verificação de validação.
Novidades na versão 0.6.13
A lista completa de notas sobre a versão desta versão está disponível no GitHub: https://github.com/Azure/data-api-builder/releases/tag/v0.6.13.
Novo comando da CLI para exportar o esquema GraphQL
Uma nova opção é adicionada para exportar o esquema GraphQL. Isso inicia o servidor DAB e, em seguida, consulta-o para obter o esquema antes de escrevê-lo no local fornecido.
dab export --graphql -c dab-config.development.json -o ./schemas
Esse comando gera o arquivo de esquema GraphQL no diretório ./schemas. O caminho para o arquivo de configuração é um parâmetro opcional, que usa como padrão 'dab-config.json' a menos que 'dab-config.<>DAB_ENVIRONMENT.json' existe, em que DAB_ENVIRONMENT é uma variável de ambiente.
Suporte à política de banco de dados para criar ação para MsSql
As políticas de banco de dados agora têm suporte para todas as operações CRUD (Criar, Ler, Atualizar, Excluir) para MsSql. Por exemplo:
"entities":{
"Revenue":{
"source": "revenues",
"permissions":[
"role": "authenticated",
"actions": [
{
"action": "Create",
"policy": {
"database": "@item.revenue gt 0"
}
},
"read",
"update",
"delete"
]
]
}
}
A configuração anterior da Revenue
entidade indica que o usuário que está executando uma operação de inserção com função Authenticated
não tem permissão para criar um registro com receita menor ou igual a zero.
Capacidade de configurar o caminho do GraphQL e desabilitar pontos de extremidade REST e GraphQL globalmente por meio da CLI
Agora damos suporte a mais três opções para o init
comando:
graphql.path
: para fornecer o caminho personalizado do GraphQLrest.disabled
: para desabilitar os pontos de extremidade REST globalmentegraphql.disabled
: para desabilitar os pontos de extremidade do GraphQL globalmente
Por exemplo, um init
comando geraria um arquivo de configuração com uma seção de runtime:
dab init --database-type mssql --rest.disabled --graphql.disabled --graphql.path /gql
"runtime": {
"rest": {
"enabled": false,
"path": "/api"
},
"graphql": {
"allow-introspection": true,
"enabled": false,
"path": "/gql"
},
}
Campos-chave obrigatórios para adicionar e atualizar exibições na CLI
Agora é obrigatório que o usuário forneça os campos de chave (a serem usados como chave primária) por meio da opção source.key-fields
exposta sempre que adicionar uma nova exibição de banco de dados (via dab add
) à configuração por meio da CLI. Além disso, sempre que atualizar algo na configuração do modo de exibição (via dab update
) no arquivo de configuração por meio da CLI, se a atualização alterar algo relacionado à definição da exibição no banco de dados subjacente (por exemplo, tipo de origem, key-fields), também será obrigatório especificar os campos-chave no comando update.
No entanto, ainda há suporte para exibições sem ter chaves primárias explícitas especificadas na configuração, mas a configuração para essas exibições precisa ser gravada diretamente no arquivo de configuração.
Por exemplo, um dab add
comando é usado para adicionar uma exibição:
dab add books_view --source books_view --source.type "view" --source.key-fields "id" --permissions "anonymous:*" --rest true --graphql true
Esse comando gera a configuração para books_view
a entidade que é semelhante a este exemplo:
"books_view": {
"source": {
"type": "view",
"object": "books_view",
"key-fields":[
"id"
]
},
"permissions": [
{
"role": "anonymous",
"actions": [
"*"
]
}
],
"rest": true,
"graphql": true
}
Substituindo o link de armazenamento do Azure por links do GitHub
Como o DAB agora é de software livre, não precisamos baixar os artefatos da conta de armazenamento. Em vez disso, podemos baixá-los diretamente do GitHub. Portanto, os links são atualizados adequadamente.
Novidades na versão 0.5.34
A lista completa de notas sobre a versão desta versão está disponível no GitHub: https://github.com/Azure/data-api-builder/releases/tag/v0.5.34.
Respeitar o sinalizador rest e o sinalizador habilitado para GraphQL no nível do runtime
Uma nova opção é adicionada para permitir habilitar ou desabilitar solicitações REST/GraphQL para todas as entidades no nível do runtime. Se desabilitada globalmente, nenhuma entidade estaria acessível por meio de solicitações REST ou GraphQL, independentemente das configurações de entidade individuais. Se habilitadas globalmente, as entidades individuais poderão ser acessadas por padrão, a menos que sejam desabilitadas explicitamente pelas configurações de nível de entidade.
"runtime": {
"rest": {
"enabled": false,
"path": "/api"
},
"graphql": {
"allow-introspection": true,
"enabled": false,
"path": "/graphql"
}
}
ID de correlação nos logs de solicitação
Para ajudar na depuração, anexamos uma ID de correlação a todos os logs gerados durante uma solicitação. Como muitas solicitações podem ser feitas, é importante ter uma maneira de identificar os logs de uma solicitação específica para ajudar no processo de depuração.
Suporte à operação curinga para procedimentos armazenados no mecanismo e na CLI
Para procedimentos armazenados, as funções agora podem ser configuradas com a ação curinga *
, mas ela só se expande para a ação execute
.
Novidades na versão 0.5.32
A lista completa de notas sobre a versão desta versão está disponível no GitHub: https://github.com/Azure/data-api-builder/releases/tag/v0.5.32-beta.
Capacidade de personalizar o caminho de repouso por meio da CLI
Uma nova opção --rest.path
é introduzida no init
comando para personalizar o caminho para APIs REST.
dab init --database-type mssql --connection-string "Connection-String" --rest.path "rest-api"
Esse comando configura os pontos de extremidade REST com um prefixo de rest-api
. O caminho completo para os pontos de extremidade REST é https://<dab-server>/rest-api/<entity-name>
Quando --rest.path
a opção não é usada, os pontos de extremidade REST são configurados com o prefixo api
padrão . O caminho completo nesse caso é https://<dab-server>/api/<entity-name>
Imagem de contêiner do Construtor de API de Dados no MAR
As imagens oficiais do Docker para o Construtor de API de Dados para Bancos de Dados do Azure agora estão disponíveis no Microsoft Artifact Registry.
Para obter instruções sobre como usar as imagens publicadas, consulte Registro de contêiner da Microsoft – Construtor de API de Dados.
Suporte para fragmentos do GraphQL
Os fragmentos são parte reutilizável de uma consulta graphQL. Em cenários em que os mesmos campos precisam ser consultados em consultas diferentes, os campos repetidos podem ser consolidados em um único componente reutilizável chamado fragmento.
Para obter mais informações sobre fragmentos, consulte Consultas do GraphQL.
Um fragmento chamado description
no tipo Character
é definido em seguida:
fragment description on Character {
name
homePlanet
primaryFunction
}
Uma consulta GraphQL que usa o fragmento definido pode ser construída conforme ilustrado aqui:
{
Player1: Player{
id
playerDescription{
...description
}
}
}
Para a consulta anterior, o resultado contém os seguintes campos:
{
Player1: Player{
id
playerDescription{
name
homePlanet
primaryFunction
}
}
}
Ativar o BinSkim e corrigir alertas do Policheck
BinSkim é um verificador leve pe (Executável Portátil) que valida as configurações do compilador/vinculador e outras características binárias relevantes à segurança. Uma tarefa de pipeline no static-tools
pipeline é adicionada para executar verificações binSkim a cada execução de pipeline. O sistema PoliCheck é um conjunto de ferramentas e dados que ajuda a manter a conformidade com o Requisito de Revisão de Texto e Código, como parte da política geral de Preparação Global. Os alertas gerados pelas verificações policheck são corrigidos para serem compatíveis com termos confidenciais.
Novidades na versão 0.5.0
A lista completa de notas sobre a versão desta versão está disponível no GitHub: https://github.com/Azure/data-api-builder/releases/tag/v0.5.0-beta.
Esquema JSON público
O esquema JSON público oferece suporte para "intelliSense", se você estiver usando um IDE como o Visual Studio Code que dá suporte a esquemas JSON. O basic-empty-dab-config.json
arquivo na samples
pasta tem um exemplo de ponto de partida ao criar manualmente o dab-config.json
arquivo.
NuGet público Microsoft.DataApiBuilder
Microsoft.DataApiBuilder
agora está disponível como um pacote NuGet público aqui para facilitar a instalação usando a ferramenta dotnet da seguinte maneira:
dotnet tool install --global Microsoft.DataApiBuilder
Nova execute
ação para procedimentos armazenados no SQL do Azure
Uma nova execute
ação é introduzida como a única ação permitida na permissions
seção do arquivo de configuração somente quando um tipo de origem faz backup de uma entidade de stored-procedure
. Por padrão, somente POST
o método é permitido para essas entidades e somente a operação GraphQL mutation
é configurada com o prefixo execute
adicionado ao nome. Especificar explicitamente o permitido methods
na rest
seção do arquivo de configuração substitui esse comportamento. Da mesma forma, para o GraphQL, o operation
graphql
na seção pode ser substituído para ser query
em vez disso. Para obter mais informações, consulte exibições e procedimentos armazenados.
Nova mappings
seção
Na seção em mappings
cada entity
, os mapeamentos entre nomes de campo de objeto de banco de dados e seus nomes de campo expostos correspondentes são definidos para pontos de extremidade REST e GraphQL.
O formato é:
<database_field>: <entity_field>
Por exemplo:
"mappings":{
"title": "descriptions",
"completed": "done"
}
O title
campo no objeto de banco de dados relacionado é mapeado para description
o campo no tipo GraphQL ou na carga de solicitação e resposta REST.
Suporte para Contexto de Sessão no SQL do Azure
Para habilitar uma camada extra de Segurança (por exemplo, RLS (Segurança em Nível de Linha), o DAB agora dá suporte ao envio de dados para o banco de dados subjacente do Sql Server por meio de SESSION_CONTEXT. Para obter mais detalhes, consulte este documento detalhado sobre SESSION_CONTEXT: Runtime para Autorização de Banco de Dados.
Suporte para filtro em objetos aninhados em um documento no PostgreSQL
Com o PostgreSQL, agora você pode usar a relação de objeto ou matriz definida em seu esquema, que permite fazer operações de filtro nos objetos aninhados, assim como o SQL do Azure.
query {
books(filter: { series: { name: { eq: "Foundation" } } }) {
items {
title
year
pages
}
}
}
Suporte à lista escalar no NoSQL do Cosmos DB
A capacidade de consultar List
escalares agora é adicionada para o Cosmos DB.
Considere essa definição de tipo.
type Planet @model(name:"Planet") {
id : ID,
name : String,
dimension : String,
stars: [Star]
tags: [String!]
}
Agora é possível executar uma consulta que busca uma Lista, como
query ($id: ID, $partitionKeyValue: String) {
planet_by_pk (id: $id, _partitionKeyValue: $partitionKeyValue) {
tags
}
}
Suporte avançado ao registro em log usando o nível de log
- Os níveis de log padrão para o mecanismo quando
host.mode
éProduction
eDevelopment
são atualizados paraError
eDebug
respectivamente. - Durante a inicialização do mecanismo, para cada coluna de uma entidade, informações como nomes de campo expostos e a chave primária são registradas. Esse comportamento ocorre mesmo quando o mapeamento de campo é gerado automaticamente.
- No cenário de execução local, todas as consultas geradas e executadas durante a inicialização do mecanismo são registradas no
Debug
nível. - Para cada entidade, campos de relação como
source.fields
,target.fields
ecardinality
são registrados. Se houver relações muitos-muitos,linking.object
,linking.source.fields
elinking.target.fields
inferidos do banco de dados (ou do arquivo de configuração) serão registrados. - Para cada solicitação de entrada, a função e o status de autenticação da solicitação são registrados.
- Na CLI, a
Microsoft.DataAPIBuilder
versão é registrada junto com os logs associados à execução do respectivo comando.
CLI atualizada
--no-https-redirect
a opção é adicionada aostart
comando . Com essa opção, o redirecionamento automático de solicitações dehttp
parahttps
pode ser evitado.No MsSql, o contexto de sessão pode ser habilitado usando
--set-session-context true
noinit
comando . Um comando de exemplo é mostrado neste exemplo:dab init --database-type mssql --connection-string "Connection String" --set-session-context true
Detalhes de autenticação, como o provedor, o público-alvo e o emissor, podem ser configurados usando as opções
--auth.provider
,--auth.audience
e--auth.issuer.
noinit
comando . Um comando de exemplo é mostrado neste exemplo:dab init --database-type mssql --auth.provider AzureAD --auth.audience "audience" --auth.issuer "issuer"
Mensagens de erro amigáveis quando o nome da entidade não é especificado.
Novidades na versão 0.4.11
A lista completa de notas sobre a versão desta versão está disponível no GitHub: https://github.com/Azure/data-api-builder/releases/tag/v0.4.11-alpha.
Esquema JSON atualizado para a data-source
seção
A data-source
seção no arquivo de configuração é atualizada para ser consistente em todos os bancos de dados com suporte, mas ainda permite que cada banco de dados tenha configurações personalizadas. Uma nova seção options
é introduzida para agrupar todas as propriedades específicas de um banco de dados. Por exemplo:
{
"$schema": "https://dataapibuilder.azureedge.net/schemas/v0.4.11-alpha/dab.draft.schema.json",
"data-source": {
"database-type": "cosmosdb_nosql",
"options": {
"database": "PlaygroundDB",
"graphql-schema": "schema.gql"
},
"connection-string": "AccountEndpoint=https://localhost:8081/;AccountKey=REPLACEME;"
}
}
Os elementos disponíveis na options
seção dependem do escolhido database-type
.
Suporte para filtro em objetos aninhados em um documento no SQL do Azure e no SQL Server
Com o SQL do Azure e o SQL Server, você pode usar a relação de objeto ou matriz definida em seu esquema, que permite fazer operações de filtro nos objetos aninhados.
query {
books(filter: { series: { name: { eq: "Foundation" } } }) {
items {
title
year
pages
}
}
}
Suporte a procedimentos armazenados aprimorados
Suporte completo para procedimento armazenado em REST e GraphQL. Procedimento armazenado com parâmetros agora 100% com suporte. Confira a documentação Procedimentos Armazenados para saber como usar o Construtor de API de Dados com procedimentos armazenados.
Novo database-type
valor renomeado para Cosmos DB
Adicionamos suporte para a API do PostgreSQL com o Cosmos DB. Com uma seção consolidada data-source
, o atributo database-type
indica o tipo de banco de dados. Como o Cosmos DB dá suporte a várias APIs, os tipos de banco de dados com suporte no momento são cosmosdb_nosql
e cosmosdb_postgresql
.
"data-source": {
"database-type": "cosmosdb_nosql",
"options": {
"database": "PlaygroundDB",
"graphql-schema": "schema.gql"
}
}
Renomeando propriedades da CLI para cosmosdb_nosql
Após as alterações de configuração descritas nas seções anteriores, agora as propriedades da CLI são renomeada de acordo como cosmosdb_nosql-database
e cosmosdb_nosql-container
para a API NoSQL do Cosmos DB.
dab init --database-type "cosmosdb_nosql" --graphql-schema schema.gql --cosmosdb_nosql-database PlaygroundDB --cosmosdb_nosql-container "books" --connection-string "AccountEndpoint=https://localhost:8081/;AccountKey=REPLACEME;" --host-mode "Development"
A Identidade Gerenciada agora tem suporte com o Postgres
Agora, o usuário pode, como alternativa, especificar o token de acesso na configuração para autenticar com uma Identidade Gerenciada. Como alternativa, agora o usuário simplesmente não pode especificar a senha na cadeia de conexão e o runtime tenta buscar o token de identidade gerenciada padrão. Se isso falhar, a conexão será tentada sem uma senha na cadeia de conexão.
Suporte à autenticação de usuário do Microsoft Entra ID para MySQL do Azure
Adicionado o token de usuário como campo de senha para autenticar com o MySQL com o plug-in da ID do Microsoft Entra.
Novidades na versão 0.3.7
A lista completa de notas sobre a versão desta versão está disponível no GitHub: https://github.com/Azure/data-api-builder/releases/tag/v0.3.7-alpha.
Exibir suporte
Agora há suporte para exibições no REST e no GraphQL. Se você tiver uma exibição, por exemplo dbo.vw_books_details
, ela poderá ser exposta usando o seguinte dab
comando:
dab add BookDetail --source dbo.vw_books_details --source.type View --source.key-fields "id" --permissions "anonymous:read"
A source.key-fields
opção é usada para especificar quais campos do modo de exibição são usados para identificar exclusivamente um item, para que a navegação por chave primária também possa ser implementada para exibições. É responsabilidade do desenvolvedor configurar o DAB para habilitar ou desabilitar ações (por exemplo, a ação create
) dependendo se a exibição for atualizável ou não.
Suporte a procedimentos armazenados
Agora há suporte para procedimentos armazenados para solicitações REST. Se você tiver um procedimento armazenado, por exemplo dbo.stp_get_all_cowritten_books_by_author
, ele poderá ser exposto usando o seguinte dab
comando:
dab add GetCowrittenBooksByAuthor --source dbo.stp_get_all_cowritten_books_by_author --source.type "stored-procedure" --permissions "anonymous:read" --rest true
O parâmetro pode ser passado na cadeia de caracteres de consulta de URL ao chamar o ponto de extremidade REST:
http://<dab-server>/api/GetCowrittenBooksByAuthor?author=isaac%20asimov
Observação
É responsabilidade do desenvolvedor configurar o DAB para habilitar ou desabilitar ações (por exemplo, a ação create
) para permitir ou negar verbos HTTP específicos ao chamar o procedimento armazenado. Por exemplo, para o procedimento armazenado usado no exemplo, considerando que sua finalidade é retornar alguns dados, faria sentido permitir apenas a ação read
.
Autenticação de ID do Microsoft Entra
A autenticação de ID do Microsoft Entra agora está funcionando totalmente. Para obter mais informações, consulte autenticação com a ID do Microsoft Entra.
Novo provedor de autenticação de simulador para autenticação local
Para simplificar o teste de solicitações autenticadas ao desenvolver localmente, um novo simulator
provedor de autenticação está disponível. O provedor simulator
é um provedor de autenticação configurável, que instrui o mecanismo do construtor de API de Dados a tratar todas as solicitações como autenticadas. Mais detalhes aqui: Autenticação Local
Suporte para filtro em objetos aninhados em um documento no Azure Cosmos DB
Com o Azure Cosmos DB, você pode usar a relação de objeto ou matriz definida em seu esquema, que permite fazer operações de filtro nos objetos aninhados.
query {
books(first: 1, filter : { author : { profile : { twitter : {eq : ""@founder""}}}})
id
name
}
}