Informations de référence sur les fonctionnalités spécifiques à la base de données pour le générateur d’API de données

Cette référence couvre les fonctionnalités, les comportements et les exigences spécifiques à une ou plusieurs plateformes de base de données prises en charge par le générateur d’API de données (DAB). Pour obtenir une matrice de comparaison des fonctionnalités entre bases de données, consultez la disponibilité des fonctionnalités.

Prise en charge des versions de base de données

DAB prend en charge les plateformes de base de données suivantes. Les exigences de version minimales s’appliquent aux déploiements autogérés. Les bases de données PaaS (Platform-as-a-service) n’ont pas de configuration minimale requise pour la version, car le service gère la version.

SQL Server et Azure SQL

SESSION_CONTEXT

Pour SQL Server et Azure SQL, DAB peut propager les revendications utilisateur authentifiées à la base de données en appelant sp_set_session_context avant d’exécuter chaque requête. Ce mécanisme permet aux stratégies de sécurité au niveau des lignes sql natives et aux procédures stockées de lire l’identité de l’appelant à partir du moteur de base de données.

Lorsqu’il set-session-context est activé dans la configuration DAB, DAB envoie toutes les revendications authentifiées en tant que paires clé-valeur :

EXEC sp_set_session_context 'roles', 'editor', @read_only = 0;
EXEC sp_set_session_context 'oid', 'a1b2c3d4-...', @read_only = 0;
-- Your query executes after claims are set
SELECT * FROM dbo.Documents;

Les revendications courantes envoyées incluentroles, suboidet toutes les revendications personnalisées que votre fournisseur d’identité inclut dans le JWT.

Activer SESSION_CONTEXT

Définir --set-session-context true lors de l’appel dab init:

dab init \
  --database-type mssql \
  --connection-string "@env('SQL_CONNECTION_STRING')" \
  --set-session-context true

Ou définissez la propriété directement dans dab-config.json:

{
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('SQL_CONNECTION_STRING')",
    "options": {
      "set-session-context": true
    }
  }
}

Utiliser SESSION_CONTEXT dans SQL

Après l’activation set-session-context, vos objets SQL peuvent lire les valeurs de revendication :

-- Read a claim in a stored procedure
DECLARE @role NVARCHAR(256) = CAST(SESSION_CONTEXT(N'roles') AS NVARCHAR(256));

-- Use a claim in a row-level security predicate function
CREATE FUNCTION dbo.RlsPredicate(@claimRole NVARCHAR(256))
RETURNS TABLE
WITH SCHEMABINDING
AS RETURN SELECT 1 AS result
WHERE @claimRole = CAST(SESSION_CONTEXT(N'roles') AS NVARCHAR(256));

Pour obtenir une procédure pas à pas complète, consultez Implémenter la sécurité au niveau des lignes avec le contexte de session.

SESSION_CONTEXT et regroupement de connexions

DAB réinitialise toutes les valeurs de contexte de session au début de chaque requête. Toutefois, étant donné que set-session-context force la sémantique de connexion par utilisateur, la réutilisation des connexions entre les utilisateurs est évitée automatiquement lorsque cette option est activée.

Variantes de chaîne de connexion

Utilisations Microsoft.Data.SqlClient DAB pour SQL Server et Azure SQL. La bibliothèque prend en charge ces formats de chaîne de connexion.

Formats courants :

Types de données non pris en charge

Les types de données SQL Server et Azure SQL suivants ne sont pas pris en charge par DAB :

Azure Cosmos DB pour NoSQL

Configuration requise pour le schéma

Contrairement aux bases de données relationnelles, Azure Cosmos DB pour NoSQL est indépendant du schéma. DAB ne peut pas introspecter un conteneur Cosmos DB pour générer des types GraphQL. Vous devez fournir un fichier de schéma GraphQL (.gql) qui définit votre structure de document.

Le fichier de schéma utilise le langage SDL (GraphQL Schema Definition Language) standard avec deux directives personnalisées :

@model Directive

La @model(name: "...") directive est requise sur chaque type GraphQL que vous exposez via DAB. La name valeur doit correspondre exactement au nom de l’entité dans votre fichier de configuration DAB.

type Book @model(name: "Book") {
  id: ID
  title: String
  year: Int
}

@authorize Directive

La @authorize directive fournit un contrôle d’accès au niveau du champ et au niveau du type pour les requêtes GraphQL Cosmos DB. Il accepte un roles paramètre répertoriant les rôles qui peuvent accéder au champ ou au type.

type Book @model(name: "Book") {
  id: ID
  title: String @authorize(roles: ["authenticated", "librarian"])
  internalNotes: String @authorize(roles: ["editor"])
}

Vous pouvez également appliquer @authorize au niveau du type :

type InternalReport @model(name: "InternalReport") @authorize(roles: ["auditor"]) {
  id: ID
  summary: String
}

Pour obtenir un guide complet de configuration, consultez Configurer le générateur d’API de données pour Azure Cosmos DB pour NoSQL.

Indisponibilité de l’API REST

DAB ne génère pas de points de terminaison REST pour Azure Cosmos DB pour NoSQL. Azure Cosmos DB fournit une API REST native complète pour les opérations de document. Seuls les points de terminaison GraphQL sont générés. Les documents OpenAPI ne sont pas générés pour les entités Cosmos DB.

Pour accéder aux données via REST, utilisez directement l’API REST Azure Cosmos DB .

Fonctionnalités non prises en charge pour Cosmos DB

Les fonctionnalités suivantes ne sont pas prises en charge pour Azure Cosmos DB pour NoSQL :

PostgreSQL

Version minimale

PostgreSQL 11 ou version ultérieure est requis. DAB utilise Npgsql comme pilote PostgreSQL.

Types de données non pris en charge

Les types de données PostgreSQL suivants ne sont pas pris en charge par DAB :

Procédures stockées

Les procédures stockées ne sont pas prises en charge pour les entités PostgreSQL. Utilisez plutôt des tables et des vues.

MySQL

Version minimale

MySQL 8 ou version ultérieure est obligatoire.

Types de données non pris en charge

Les types de données MySQL suivants ne sont pas pris en charge par DAB :

Procédures stockées

Les procédures stockées ne sont pas prises en charge pour les entités MySQL. Utilisez plutôt des tables.

Azure Synapse Analytics (pool SQL dédié)

Objets pris en charge

Le pool SQL dédié prend en charge les tables, les vues et les procédures stockées, identiques à SQL Server et Azure SQL. Le pool SQL serverless n’est pas pris en charge.

Fonctionnalités non prises en charge

Contenu connexe

• Disponibilité des fonctionnalités
• Informations de référence sur la configuration de la source de données
• Implémenter la sécurité au niveau des lignes avec le contexte de session
• Configurer le générateur d’API de données pour Azure Cosmos DB pour NoSQL
• Stratégies de mise en production et de contrôle de version