Partager via


Nouveautés des versions 0.11 et antérieures

Notes de publication et informations sur toutes les mises à jour et améliorations dans data API Builder version 0.11 et antérieure.

Nouveautés de la version 0.11

Notes de publication et informations sur les mises à jour et les améliorations dans data API Builder version 0.10.

Prise en charge de GraphQL pour SQL Data Warehouse

SQL Data Warehouse prend désormais en charge les points de terminaison GraphQL.

Filtrage amélioré d’Azure Cosmos DB for NoSQL

Azure Cosmos DB for NoSQL prend désormais en charge les filtres imbriqués, les variables d’ID et les recherches de tableau de chaînes avec l’opérateur contains .

Activer la collecte de données d’application avec l’interface de ligne de commande

Vous pouvez maintenant utiliser l’interface de ligne de commande (CLI) DAB pour activer la collecte de données avec Application Insights.

Nouveautés de la version 0.10

Notes de publication et informations sur les mises à jour et les améliorations dans data API Builder version 0.10.

Nous nous concentrons sur la stabilité à mesure que nous approchons de la disponibilité générale. Bien que tous les efforts en matière de qualité du code et de stabilité du moteur ne soient pas détaillés dans cet article, cette liste met en évidence les mises à jour significatives.

Notes de publication de GitHub

Consultez ces pages de publication pour obtenir une liste complète de toutes les modifications et améliorations :

Mise en cache en mémoire

La version 0.10 introduit la mise en cache en mémoire pour les points de terminaison REST et GraphQL. Cette fonctionnalité, conçue pour la mise en cache interne, jette les bases d’une mise en cache distribuée ultérieure. La mise en cache en mémoire réduit la charge de la base de données à partir de requêtes répétitives.

Scénarios de mise en cache

  • Réduction de la charge de la base de données : le cache stocke les résultats des requêtes coûteuses, éliminant ainsi la nécessité d’appels de base de données répétés.
  • Amélioration de la scalabilité des API : la mise en cache prend en charge les appels d’API plus fréquents sans augmenter les demandes de base de données, ce qui permet de mettre à l’échelle considérablement les fonctionnalités de votre API.

Modifications de configuration

Les paramètres de mise en cache sont disponibles dans la runtime section et pour chaque entité, offrant un contrôle granulaire.

Paramètres d’exécution :

{
  "runtime": {
    "cache": {
      "enabled": true,
      "ttl-seconds": 6
    }
  }
}
  • La mise en cache est désactivée par défaut.
  • La durée de vie (TTL) par défaut est de 5 secondes.

Paramètres d’entité :

{
  "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
    }
  }
}

Validation de la configuration dans l’interface CLI

L’interface CLI prend désormais en charge dab validate la vérification des fichiers de configuration à la recherche d’erreurs ou d’incohérences, ce qui améliore le flux de travail de développement.

Étapes de validation

  1. Validation de schéma
  2. Validation des propriétés de configuration
  3. Configuration de la validation des autorisations
  4. Validation de la connexion de base de données
  5. Validation des métadonnées d’entités

Fonctionnalités de préversion

  • Prise en charge initiale de DWSQL. #1864
  • Prise en charge de plusieurs sources de données. #1709

Nouveautés de la version 0.9

Voici les détails sur les modifications et améliorations les plus pertinentes dans Data API Builder 0.9.

Notes de publication de GitHub

Consultez ces pages de publication pour obtenir une liste complète de toutes les modifications et améliorations :

Activer Application Insights lors de l’auto-hébergement de DAB

Les journaux peuvent désormais être diffusés en continu vers Application Insights pour une meilleure expérience de supervision et de débogage, en particulier lorsque le générateur d’API de données est déployé dans Azure. Une nouvelle telemetry section peut être ajoutée au fichier de configuration pour activer et configurer l’intégration à 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
    }
}

Lisez tous les détails dans la page de documentation Utiliser Application Insights .

Prise en charge de l’ignorance des champs superflus dans le corps de la requête REST

Avec la nouvelle request-body-strict option, vous pouvez maintenant décider si le fait d’avoir un champ supplémentaire dans la charge utile REST génère une erreur (comportement par défaut, compatibilité descendante) ou si les champs supplémentaires sont ignorés silencieusement.

"runtime": {
    "rest": {
      "enabled": true,
      "path": "/api",
      "request-body-strict": true
    },
    ...
}

En définissant l’option request-body-strict sur false, les champs qui n’ont pas de mappage à l’objet de base de données associé sont ignorés sans générer d’erreur.

Ajout d’un nom d’application pour mssql les connexions

Le générateur d’API de données injecte désormais dans la chaîne de connexion, pour mssql les types de base de données uniquement, la valeur dab-<version> en tant que Application Name propriété, ce qui facilite l’identification des connexions dans le serveur de base de données. Si Application Name est déjà présent dans la chaîne de connexion, la version du générateur d’API de données y est ajoutée.

Type de données de prise en charge time dans mssql

time le type de données est désormais pris en charge dans les mssql bases de données.

Mutations sur la table avec des déclencheurs pour mssql

Les mutations sont désormais entièrement prises en charge sur les tables avec des déclencheurs pour mssql les bases de données.

Empêcher la mise à jour/l’insertion de champs en lecture seule dans une table par l’utilisateur

Détectez automatiquement les champs en lecture seule de la base de données et empêchez la mise à jour/l’insertion de ces champs par l’utilisateur.

Nouveautés de la version 0.8

Voici les détails sur les modifications et améliorations les plus pertinentes dans Data API Builder 0.8.

Notes de publication de GitHub

Consultez ces pages de publication pour obtenir une liste complète de toutes les modifications et améliorations :

Ajout de la prise en charge du fichier .env

Les variables d’environnement protègent les secrets de l’exposition en texte brut et autorisent l’échange de valeurs dans différents paramètres. Toutefois, ces variables doivent être définies dans l’étendue de l’utilisateur ou de l’ordinateur, ce qui peut entraîner un « saignement » de la variable entre projets si les noms de variables sont dupliqués. La meilleure alternative est les fichiers d’environnement. Pour plus d’informations, consultez fichiers d’environnement dans le générateur d’API de données - blog.

Nouveautés de la version 0.7.6

Cet article décrit les notes de publication de la version 0.7.6.

Demandes de tirage GitHub

Prise en charge initiale de la création de documents de description OpenAPI v3-0-1

Data API Builder prend en charge la norme OpenAPI pour générer et exposer des documents de description qui contiennent des informations utiles sur le service. Ces documents sont créés à partir du fichier de configuration du runtime et des métadonnées de chaque objet de base de données. Ces objets sont associés à une entité rest activée définie dans ce même fichier de configuration. Elles sont ensuite exposées via une interface utilisateur et rendues disponibles sous forme de fichier sérialisé.

Pour plus d’informations sur les spécificités d’OpenAPI et du générateur d’API de données, consultez OpenAPI.

Autorisation de la fusion des fichiers de configuration

Ajoute la possibilité de fusionner automatiquement deux fichiers de configuration.

Il est possible de gérer plusieurs paires de fichiers de configuration de base et spécifiques à l’environnement pour simplifier la gestion des paramètres spécifiques de l’environnement. Par exemple, il est possible de gérer des configurations distinctes pour le développement et la production. Cette étape implique de disposer d’un fichier de configuration de base qui contient tous les paramètres communs entre les différents environnements. Ensuite, en définissant la DAB_ENVIRONMENT variable, il est possible de contrôler les fichiers de configuration à fusionner pour être consommés par le générateur d’API de données.

Pour plus d’informations, consultez Informations de référence sur l’interface CLI.

Exécution de mutations GraphQL et REST dans une transaction

Le générateur d’API de données crée des transactions de base de données pour exécuter certains types de requêtes GraphQL et REST.

Il existe de nombreuses demandes, qui impliquent l’exécution de plusieurs requêtes de base de données. Par exemple, pour retourner les résultats d’une mise à jour, une requête doit d’abord être effectuée pour la mise à jour, puis les nouvelles valeurs doivent être lues avant d’être retournées. Lorsqu’une requête nécessite l’exécution de plusieurs requêtes de base de données, le Générateur d’API de données exécute désormais ces requêtes de base de données au sein d’une seule transaction.

Vous pouvez en savoir plus sur cette fonctionnalité dans le contexte de REST dans la documentation REST et de GraphQL dans la documentation GraphQL.

Nouveautés de la version 0.6.14

Cet article décrit le correctif de la version de mars 2023 pour le générateur d’API de données pour Azure Database.

Correctifs de bogues

  • Résoudre le problème d’accès refusé au filtre de requête pour Cosmos.
  • Cosmos DB ne prend actuellement pas en charge l’autorisation au niveau du champ. Pour éviter que les utilisateurs passent accidentellement les autorisations dans la field configuration du runtime, nous avons ajouté un contrôle de validation.

Nouveautés de la version 0.6.13

La liste complète des notes de publication de cette version est disponible sur GitHub : https://github.com/Azure/data-api-builder/releases/tag/v0.6.13.

Nouvelle commande CLI pour exporter le schéma GraphQL

Une nouvelle option est ajoutée pour exporter le schéma GraphQL. Cela démarre le serveur DAB, puis l’interroge pour obtenir le schéma avant de l’écrire à l’emplacement fourni.

dab export --graphql -c dab-config.development.json -o ./schemas

Cette commande génère le fichier de schéma GraphQL dans le répertoire ./schemas. Le chemin d’accès au fichier de configuration est un paramètre facultatif, qui est défini par défaut sur « dab-config.json », sauf si « dab-config ».<>DAB_ENVIRONMENT.json' existe, où DAB_ENVIRONMENT est une variable d’environnement.

Prise en charge de la stratégie de base de données pour créer une action pour MsSql

Les stratégies de base de données sont désormais prises en charge pour toutes les opérations CRUD (Create, Read, Update, Delete) pour MsSql. Par exemple :

"entities":{
  "Revenue":{
    "source": "revenues",
    "permissions":[
      "role": "authenticated",
          "actions": [
            {
              "action": "Create",
              "policy": {
                "database": "@item.revenue gt 0"
              }
            },
            "read",
            "update",
            "delete"
          ]
    ]
  }
}

La configuration précédente de Revenue l’entité indique que l’utilisateur qui effectue une opération d’insertion avec un rôle Authenticated n’est pas autorisé à créer un enregistrement avec un chiffre d’affaires inférieur ou égal à zéro.

Possibilité de configurer le chemin d’accès GraphQL et de désactiver globalement les points de terminaison REST et GraphQL via l’interface CLI

Nous prenons désormais en charge trois autres options pour la init commande :

  • graphql.path : pour fournir un chemin GraphQL personnalisé
  • rest.disabled: Pour désactiver les points de terminaison REST globalement
  • graphql.disabled: Pour désactiver les points de terminaison GraphQL globalement

Par exemple, une init commande génère un fichier de configuration avec une section 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"
    },
}

Champs clés obligatoires pour l’ajout et la mise à jour de vues dans l’interface CLI

Il est désormais obligatoire pour l’utilisateur de fournir les champs de clé (à utiliser comme clé primaire) via l’option source.key-fields exposée chaque fois qu’une nouvelle vue de base de données (via dab add) est ajoutée à la configuration via l’interface CLI. En outre, chaque fois que vous mettez à jour quelque chose dans la configuration de la vue (via dab update) dans le fichier de configuration via l’interface CLI, si la mise à jour change quelque chose qui concerne la définition de la vue dans la base de données sous-jacente (par exemple, le type de source, key-fields), il est obligatoire de spécifier également les champs clés dans la commande de mise à jour.

Toutefois, nous prenons toujours en charge les vues sans avoir de clés primaires explicites spécifiées dans la configuration, mais la configuration de ces vues doit être écrite directement dans le fichier de configuration.

Par exemple, une dab add commande est utilisée pour ajouter une vue :

dab add books_view --source books_view --source.type "view" --source.key-fields "id" --permissions "anonymous:*" --rest true --graphql true

Cette commande génère la configuration de l’entité books_view qui est semblable à cet exemple :

"books_view": {
      "source": {
        "type": "view",
        "object": "books_view",
        "key-fields":[
          "id"
        ]
      },
      "permissions": [
        {
          "role": "anonymous",
          "actions": [
            "*"
          ]
        }
      ],
      "rest": true,
      "graphql": true
    }

Étant donné que DAB est désormais open source, nous n’avons pas besoin de télécharger les artefacts à partir du compte de stockage. Au lieu de cela, nous pouvons les télécharger directement à partir de GitHub. Par conséquent, les liens sont mis à jour en conséquence.

Nouveautés de la version 0.5.34

La liste complète des notes de publication de cette version est disponible sur GitHub : https://github.com/Azure/data-api-builder/releases/tag/v0.5.34.

Respecter l’indicateur ACTIVÉ PAR REST et GraphQL au niveau de l’exécution

Une nouvelle option est ajoutée pour autoriser l’activation ou la désactivation des requêtes REST/GraphQL pour toutes les entités au niveau de l’exécution. Si elle est désactivée globalement, aucune entité ne serait accessible via des requêtes REST ou GraphQL, quels que soient les paramètres d’entité individuels. Si cette option est activée globalement, les entités individuelles sont accessibles par défaut, sauf si elles sont désactivées explicitement par les paramètres au niveau de l’entité.

"runtime": {
    "rest": {
      "enabled": false,
      "path": "/api"
    },
    "graphql": {
      "allow-introspection": true,
      "enabled": false,
      "path": "/graphql"
    }
  }

ID de corrélation dans les journaux des demandes

Pour faciliter le débogage, nous attachons un ID de corrélation à tous les journaux générés lors d’une demande. Étant donné que de nombreuses demandes peuvent être effectuées, il est important d’avoir un moyen d’identifier les journaux d’activité d’une demande spécifique pour faciliter le processus de débogage.

Prise en charge des opérations génériques pour les procédures stockées dans le moteur et l’interface CLI

Pour les procédures stockées, les rôles peuvent désormais être configurés avec l’action générique * , mais elle s’étend uniquement à l’action execute .

Nouveautés de la version 0.5.32

La liste complète des notes de publication de cette version est disponible sur GitHub : https://github.com/Azure/data-api-builder/releases/tag/v0.5.32-beta.

Possibilité de personnaliser le chemin de repos via l’interface CLI

Une nouvelle option --rest.path est introduite dans la init commande pour personnaliser le chemin d’accès pour les API REST.

dab init --database-type mssql --connection-string "Connection-String" --rest.path "rest-api" 

Cette commande configure les points de terminaison REST avec le préfixe rest-api. Le chemin d’accès complet pour les points de terminaison REST est https://<dab-server>/rest-api/<entity-name>

Lorsque --rest.path l’option n’est pas utilisée, les points de terminaison REST sont configurés avec le préfixe apipar défaut . Le chemin d’accès complet dans ce cas est https://<dab-server>/api/<entity-name>

Image conteneur du générateur d’API de données dans MAR

Les images Docker officielles du générateur d’API de données pour les bases de données Azure sont désormais disponibles dans Microsoft Artifact Registry.

Pour obtenir des instructions sur l’utilisation des images publiées, consultez Registre de conteneurs Microsoft - Générateur d’API de données.

Prise en charge des fragments GraphQL

Les fragments font partie réutilisable d’une requête graphQL. Dans les scénarios où les mêmes champs doivent être interrogés dans différentes requêtes, les champs répétés peuvent être consolidés dans un seul composant réutilisable appelé fragment.

Pour plus d’informations sur les fragments, consultez Requêtes GraphQL.

Un fragment appelé description sur le type Character est défini ensuite :

fragment description on Character {
  name
  homePlanet
  primaryFunction
}

Une requête GraphQL qui utilise le fragment défini peut être construite comme illustré ici :

{
  Player1: Player{
    id
    playerDescription{
        ...description
    }
  }
}

Pour la requête précédente, le résultat contient les champs suivants :

{
 Player1: Player{
    id
    playerDescription{
        name
        homePlanet
        primaryFunction
    }
  }   
}

Activer BinSkim et corriger les alertes Policheck

BinSkim est un analyseur léger exécutable portable qui vérifie les paramètres du compilateur et de l’éditeur de liens ainsi que d’autres caractéristiques des fichiers binaires relatives à la sécurité. Une tâche de pipeline dans le static-tools pipeline est ajoutée pour effectuer des analyses BinSkim à chaque exécution de pipeline. Le système PoliCheck est un ensemble d’outils et de données qui permettent de rester conforme aux exigences de révision de texte et de code, dans le cadre de la stratégie globale de préparation globale. Les alertes générées par les analyses Policheck sont corrigées pour être conformes en ce qui concerne les termes sensibles.

Nouveautés de la version 0.5.0

La liste complète des notes de publication de cette version est disponible sur GitHub : https://github.com/Azure/data-api-builder/releases/tag/v0.5.0-beta.

Schéma JSON public

Le schéma JSON public prend en charge « intellisense » si vous utilisez un IDE comme Visual Studio Code qui prend en charge les schémas JSON. Le basic-empty-dab-config.json fichier dans le samples dossier a un exemple de point de départ lors de la création manuelle du dab-config.json fichier.

Public Microsoft.DataApiBuilder NuGet

Microsoft.DataApiBuilder est désormais disponible en tant que package NuGet public ici pour faciliter l’installation à l’aide de l’outil dotnet comme suit :

dotnet tool install --global Microsoft.DataApiBuilder

Nouvelle execute action pour les procédures stockées dans Azure SQL

Une nouvelle execute action est introduite comme seule action autorisée dans la permissions section du fichier de configuration uniquement lorsqu’un type de source sauvegarde une entité de stored-procedure. Par défaut, seule POST la méthode est autorisée pour ces entités et seule l’opération GraphQL mutation est configurée avec le préfixe execute ajouté à leur nom. La spécification explicite du autorisé methods dans la rest section du fichier de configuration remplace ce comportement. De même, pour GraphQL, le operation dans la graphql section, peut être remplacé pour être query à la place. Pour plus d’informations, consultez affichages et procédures stockées.

Nouvelle mappings section

Dans la mappings section sous chaque entity, les mappages entre les noms de champs d’objet de base de données et leurs noms de champs exposés correspondants sont définis pour les points de terminaison GraphQL et REST.

Le format est le suivant :

<database_field>: <entity_field>

Par exemple :

  "mappings":{
    "title": "descriptions",
    "completed": "done"
  }

Le title champ de l’objet de base de données associé est mappé au description champ dans le type GraphQL ou dans la charge utile de requête et de réponse REST.

Prise en charge du contexte de session dans Azure SQL

Pour activer une couche de sécurité supplémentaire (par exemple, sécurité au niveau des lignes), DAB prend désormais en charge l’envoi de données à la base de données Sql Server sous-jacente via SESSION_CONTEXT. Pour plus d’informations, reportez-vous à ce document détaillé sur SESSION_CONTEXT : Autorisation du runtime vers la base de données.

Prise en charge du filtrage sur les objets imbriqués dans un document dans PostgreSQL

Avec PostgreSQL, vous pouvez maintenant utiliser la relation d’objet ou de tableau définie dans votre schéma, ce qui permet d’effectuer des opérations de filtrage sur les objets imbriqués, tout comme Azure SQL.

query {
  books(filter: { series: { name: { eq: "Foundation" } } }) {
    items {
      title
      year
      pages
    }
  }
}

Prendre en charge la liste scalaire dans Cosmos DB NoSQL

La possibilité d’interroger List scalaires est désormais ajoutée pour Cosmos DB.

Considérez cette définition de type.

type Planet @model(name:"Planet") {
    id : ID,
    name : String,
    dimension : String,
    stars: [Star]
    tags: [String!]
}

Il est désormais possible d’exécuter une requête qui extrait une liste telle que

query ($id: ID, $partitionKeyValue: String) {
    planet_by_pk (id: $id, _partitionKeyValue: $partitionKeyValue) {
        tags
    }
}

Meilleure prise en charge de la journalisation à l’aide du niveau journal

  • Niveaux de journal par défaut pour le moteur quand host.mode est Production et Development sont mis à Error jour vers et Debug respectivement.
  • Lors du démarrage du moteur, pour chaque colonne d’une entité, des informations telles que les noms de champs exposés et la clé primaire sont consignées. Ce comportement se produit même lorsque le mappage de champs est généré automatiquement.
  • Dans le scénario d’exécution locale, toutes les requêtes générées et exécutées lors du démarrage du moteur sont enregistrées au Debug niveau.
  • Pour chaque entité, les champs de relation tels que source.fields, target.fieldset cardinality sont consignés. S’il existe des relations plusieurs-plusieurs, linking.object, linking.source.fieldset linking.target.fields déduits de la base de données (ou du fichier de configuration) sont consignés.
  • Pour chaque requête entrante, le rôle et l’état d’authentification de la demande sont consignés.
  • Dans l’interface CLI, la Microsoft.DataAPIBuilder version est journalisée avec les journaux associés à l’exécution de la commande correspondante.

Interface CLI mise à jour

  • --no-https-redirect l’option est ajoutée à la start commande. Avec cette option, la redirection automatique des demandes de http vers https peut être évitée.

  • Dans MsSql, le contexte de session peut être activé à l’aide --set-session-context true de la init commande . Un exemple de commande est illustré dans cet exemple :

    dab init --database-type mssql --connection-string "Connection String" --set-session-context true
    
  • Les détails d’authentification tels que le fournisseur, l’audience et l’émetteur peuvent être configurés à l’aide des options --auth.provider, --auth.audienceet --auth.issuer. dans la init commande . Un exemple de commande est illustré dans cet exemple :

    dab init --database-type mssql --auth.provider AzureAD --auth.audience "audience" --auth.issuer "issuer"
    
  • Messagerie d’erreur conviviale lorsque le nom d’entité n’est pas spécifié.

Nouveautés de la version 0.4.11

La liste complète des notes de publication de cette version est disponible sur GitHub : https://github.com/Azure/data-api-builder/releases/tag/v0.4.11-alpha.

Schéma JSON mis à jour pour data-source la section

La data-source section du fichier de configuration est mise à jour pour être cohérente entre toutes les bases de données prises en charge, tout en permettant à chaque base de données d’avoir des configurations personnalisées. Une nouvelle section options est introduite pour regrouper toutes les propriétés spécifiques à une base de données. Par exemple :

{
  "$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;"
  }
}

Les éléments disponibles dans la options section dépendent de l’élément choisi database-type.

Prise en charge du filtre sur les objets imbriqués dans un document dans Azure SQL et SQL Server

Avec Azure SQL et SQL Server, vous pouvez utiliser la relation d’objet ou de tableau définie dans votre schéma, ce qui permet d’effectuer des opérations de filtre sur les objets imbriqués.

query {
  books(filter: { series: { name: { eq: "Foundation" } } }) {
    items {
      title
      year
      pages
    }
  }
}

Meilleure prise en charge des procédures stockées

Prise en charge complète des procédures stockées dans REST et GraphQL. Procédure stockée avec des paramètres désormais pris en charge à 100 %. Consultez la documentation procédures stockées pour découvrir comment utiliser le générateur d’API de données avec des procédures stockées.

Nouvelle database-type valeur renommée pour Cosmos DB

Nous avons ajouté la prise en charge de l’API PostgreSQL avec Cosmos DB. Avec une section consolidée data-source , l’attribut database-type désigne le type de base de données. Étant donné que Cosmos DB prend en charge plusieurs API, les types de base de données actuellement pris en charge sont cosmosdb_nosql et cosmosdb_postgresql.

  "data-source": {
    "database-type": "cosmosdb_nosql",
    "options": {
      "database": "PlaygroundDB",
      "graphql-schema": "schema.gql"
    }
  }

Renommage des propriétés CLI pour cosmosdb_nosql

Suite aux modifications de configuration décrites dans les sections précédentes, les propriétés CLI sont renommées en conséquence en tant qu’API cosmosdb_nosql-databasecosmosdb_nosql-container NoSQL 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"

Identité managée désormais prise en charge avec Postgres

À présent, l’utilisateur peut également spécifier le jeton d’accès dans la configuration pour s’authentifier auprès d’une identité managée. Sinon, l’utilisateur ne peut pas spécifier le mot de passe dans la chaîne de connexion et le runtime tente d’extraire le jeton d’identité managée par défaut. Si cela échoue, la connexion est tentée sans mot de passe dans la chaîne de connexion.

Prise en charge de l’authentification utilisateur d’ID Microsoft Entra pour Azure MySQL

Ajout du jeton utilisateur en tant que champ de mot de passe pour l’authentification auprès de MySQL avec le plug-in d’ID Microsoft Entra.

Nouveautés de la version 0.3.7

La liste complète des notes de publication de cette version est disponible sur GitHub : https://github.com/Azure/data-api-builder/releases/tag/v0.3.7-alpha.

Afficher la prise en charge

Les vues sont désormais prises en charge dans REST et GraphQL. Si vous avez une vue, par exemple dbo.vw_books_details , elle peut être exposée à l’aide de la commande suivante dab :

dab add BookDetail --source dbo.vw_books_details --source.type View --source.key-fields "id" --permissions "anonymous:read"

L’option source.key-fields est utilisée pour spécifier les champs de la vue qui sont utilisés pour identifier un élément de manière unique, afin que la navigation par clé primaire puisse également être implémentée pour les vues. Il incombe au développeur de configurer DAB d’activer ou de désactiver les actions (par exemple, l’action create ) selon que la vue est modifiable ou non.

Prise en charge des procédures stockées

Les procédures stockées sont désormais prises en charge pour les requêtes REST. Si vous avez une procédure stockée, par exemple dbo.stp_get_all_cowritten_books_by_author , elle peut être exposée à l’aide de la commande suivante dab :

dab add GetCowrittenBooksByAuthor --source dbo.stp_get_all_cowritten_books_by_author --source.type "stored-procedure" --permissions "anonymous:read" --rest true

Le paramètre peut être transmis dans la chaîne de requête d’URL lors de l’appel du point de terminaison REST :

http://<dab-server>/api/GetCowrittenBooksByAuthor?author=isaac%20asimov

Notes

Il incombe au développeur de configurer DAB pour activer ou désactiver des actions (par exemple, l’action create ) pour autoriser ou refuser des verbes HTTP spécifiques lors de l’appel de la procédure stockée. Par exemple, pour la procédure stockée utilisée dans l’exemple, étant donné que son objectif est de retourner certaines données, il serait judicieux d’autoriser uniquement l’action read .

Authentification de l’ID Microsoft Entra

L’authentification d’ID Microsoft Entra fonctionne désormais entièrement. Pour plus d’informations, consultez Authentification avec l’ID Microsoft Entra.

Nouveau fournisseur d’authentification de simulateur pour l’authentification locale

Pour simplifier le test des demandes authentifiées lors du développement local, un nouveau simulator fournisseur d’authentification est disponible. Le fournisseur simulator est un fournisseur d’authentification configurable, qui demande au moteur du générateur d’API de données de traiter toutes les requêtes comme authentifiées. Plus d’informations ici : Authentification locale

Prise en charge du filtre sur les objets imbriqués dans un document dans Azure Cosmos DB

Avec Azure Cosmos DB, vous pouvez utiliser la relation d’objet ou de tableau définie dans votre schéma, ce qui permet d’effectuer des opérations de filtre sur les objets imbriqués.

query {
  books(first: 1, filter : { author : { profile : { twitter : {eq : ""@founder""}}}})
    id
    name
  }
}