Résolution des problèmes PostgreSQL

Solutions pour les problèmes courants de connectivité, de schéma et ssl PostgreSQL dans le générateur d’API de données.

Questions courantes

Qu’est-ce que la prise en charge de PostgreSQL dans DAB ?

Le générateur d’API de données prend en charge PostgreSQL en tant que back-end de base de données relationnelle. DAB se connecte à l’aide du pilote Npgsql et traduit les requêtes REST et GraphQL en requêtes SQL. Les instances PostgreSQL auto-hébergées et les services managés tels qu’Azure Database pour PostgreSQL sont pris en charge.

Quel format de chaîne de connexion PostgreSQL utilise-t-il ?

DAB utilise une chaîne de connexion de style ADO.NET pour PostgreSQL. Une chaîne classique ressemble à Host=localhost;Port=5432;Database=mydb;Username=myuser;Password=mypassword;. Définissez la chaîne de connexion dans le champ data-source.connection-string de dab-config.json ou passez-la via --connection-string dans dab init.

DAB prend-il en charge les schémas PostgreSQL ?

Yes. DAB prend en charge les schémas non publics. Référencez explicitement le schéma dans le champ source de l’entité en utilisant le format schemaname.tablename (par exemple sales.orders). L’utilisateur de base de données configuré dans la chaîne de connexion doit avoir USAGE des privilèges sur le schéma etSELECTINSERT, ou UPDATEDELETE des privilèges sur les tables cibles.

Problèmes courants

Impossible de se connecter au conteneur PostgreSQL

Symptôme: DAB ne parvient pas à démarrer avec Failed to connect to localhost:5432 ou à une erreur réseau similaire.

Cause : Le port du conteneur PostgreSQL n’est pas mappé ou le conteneur n’est pas prêt à accepter les connexions.

Résolution : Vérifiez que le conteneur est en cours d’exécution avec docker ps et que le port 5432 est lié à l’hôte. Utiliser Host=localhost;Port=5432 dans la chaîne de connexion. Si le conteneur vient de démarrer, laissez quelques secondes pour que PostgreSQL s’initialise avant de démarrer DAB.

Échec de l’authentification par mot de passe

Symptôme: Les journaux DAB indiquent 28P01: password authentication failed for user.

Cause : Le nom d’utilisateur ou le mot de passe dans la chaîne de connexion est incorrect, ou l’utilisateur PostgreSQL est configuré pour une autre méthode d’authentification telle que peer ou ident.

Résolution: Vérifiez que les informations d’identification correspondent à celles définies lors de la création de l’instance ou du conteneur PostgreSQL. Pour les conteneurs, vérifiez les variables d’environnement POSTGRES_PASSWORD et POSTGRES_USER. En cas d’exécution locale, confirmez que pg_hba.conf permet md5 ou scram-sha-256 l'authentification de l'hôte de connexion.

Schéma introuvable lorsque l’entité fait référence à un schéma non public

Symptôme: DAB retourne une relation "tablename" does not exist erreur même si la table existe dans la base de données.

Cause : Le champ de l’entité omet le préfixe de source schéma, donc PostgreSQL recherche uniquement le public schéma par défaut.

Résolution: Mettez à jour source valeur dans dab-config.json pour inclure le préfixe de schéma, par exemple sales.orders. Vérifiez que l’utilisateur de la base de données a USAGE sur le schéma en exécutant GRANT USAGE ON SCHEMA sales TO myuser; dans psql.

Erreur SSL requise lors de la connexion à Azure Database pour PostgreSQL

Symptôme: Les connexions à Azure Database pour PostgreSQL échouent avec SSL connection is required.

Cause : Azure Database pour PostgreSQL applique SSL par défaut. Les connexions sans SSL sont rejetées.

Résolution: Ajoutez Ssl Mode=Require; à la chaîne de connexion. Pour la validation complète des certificats, définissez Trust Server Certificate=false et fournissez le chemin du certificat d’autorité de certification du serveur via Root Certificate=path/to/ca.pem. Téléchargez le bundle de certificats à partir du portail Azure sous les paramètres réseau du serveur.

Les procédures stockées ne sont pas prises en charge

Symptôme: La configuration d’une procédure stockée ou d’une fonction PostgreSQL en tant que source d’entité échoue ou l’entité ne se comporte pas comme prévu.

Cause : Le générateur d’API de données ne prend actuellement pas en charge les procédures stockées pour PostgreSQL. Il s’agit d’une limitation connue suivie dans le problème GitHub #1023.

Résolution: Utilisez plutôt une table ou une vue comme source d’entité. Suivez le ticket GitHub pour les mises à jour concernant l'ajout de la prise en charge des procédures stockées PostgreSQL.

La stratégie de base de données n’est pas appliquée pour les opérations de création

Symptôme: Une mutation de création ou une requête POST réussit même lorsqu’une stratégie de base de données doit restreindre l’opération.

Cause : La prise en charge de la stratégie de base de données pour Créer des actions dans PostgreSQL n’est pas encore implémentée. Il s’agit d’une limitation connue suivie dans le problème GitHub #1334.

Résolution: Utilisez des autorisations basées sur des rôles pour restreindre l'accès à la création jusqu'à ce que le support des stratégies de base de données pour l'opération Create de PostgreSQL soit disponible.

La stratégie de base de données n’est pas appliquée pour les opérations PUT et PATCH

Symptôme: Une requête PUT ou PATCH sur une entité PostgreSQL réussit même lorsqu’une stratégie de base de données doit la restreindre.

Cause : La prise en charge des stratégies de base de données pour les opérations PUT et PATCH dans PostgreSQL n’est pas encore implémentée. Il s’agit d’une limitation connue suivie dans le problème GitHub #1372.

Résolution: Utilisez des autorisations basées sur des rôles pour restreindre l’accès aux mises à jour jusqu’à ce que la prise en charge des stratégies de base de données pour les opérations de mise à jour PostgreSQL soit disponible.

L’authentification « On-Behalf-Of » (OBO) n’est pas prise en charge

Symptôme: La configuration de l’authentification on-Behalf-Of (OBO) pour une instance DAB soutenue par PostgreSQL échoue ou le jeton n’est pas transféré à la base de données comme prévu.

Cause : L’authentification OBO est actuellement prise en charge uniquement pour SQL Server et Azure SQL. La prise en charge de PostgreSQL, MySQL et Azure Cosmos DB n’a pas encore été implémentée. Il s’agit d’une limitation connue suivie dans le problème GitHub #3159.

Résolution: Utilisez une méthode d’authentification prise en charge, comme les informations d’identification de chaîne de connexion ou l’identité managée pour PostgreSQL. Suivez le problème GitHub pour les mises à jour sur le moment où la prise en charge de OBO est étendue aux bases de données non-SQL Server.