Résolution des problèmes mySQL

Solutions pour les problèmes courants de connectivité, d’authentification et de type de données MySQL dans le générateur d’API de données.

Questions courantes

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

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

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

DAB utilise une chaîne de connexion ADO.NET MySQL standard. Une chaîne classique ressemble à Server=localhost;Port=3306;Database=mydb;Uid=myuser;Pwd=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.

Quelles sont les versions de MySQL prises en charge ?

DAB prend en charge MySQL 8.0 et versions ultérieures. MySQL 5.7 peut fonctionner, mais n’est pas officiellement pris en charge. Confirmez la version de votre serveur avec SELECT VERSION(); dans l’interpréteur de commandes MySQL. Si vous êtes sur un service managé tel qu’Azure Database pour MySQL, utilisez le niveau Serveur flexible, qui prend en charge MySQL 8.0.

Problèmes courants

Impossible de se connecter au conteneur MySQL

Symptôme: DAB ne parvient pas à démarrer avec Unable to connect to any of the specified MySQL hosts.

Cause : Le port du conteneur MySQL n’est pas mappé, le nom d’hôte est incorrect ou le conteneur n’a pas terminé l’initialisation.

Résolution : Vérifiez que le conteneur est en cours d’exécution avec docker ps et que le port 3306 est lié à l’hôte. Utiliser Server=localhost;Port=3306 dans la chaîne de connexion. Laissez quelques secondes après le démarrage du conteneur pour MySQL pour terminer l’initialisation avant de démarrer DAB.

Accès refusé pour l’utilisateur

Symptôme : Les journaux DAB montrent Access denied for user 'myuser'@'172.x.x.x' ou un message similaire.

Cause : Le compte d’utilisateur MySQL est limité à un hôte spécifique. Lorsque DAB s’exécute dans Docker, les connexions proviennent de l’adresse IP du réseau de conteneurs, et non localhost.

Résolution: Accordez à l’utilisateur l’accès à partir de n’importe quel hôte en exécutant GRANT ALL PRIVILEGES ON mydb.* TO 'myuser'@'%' IDENTIFIED BY 'mypassword'; FLUSH PRIVILEGES;. Pour la production, remplacez % par l’hôte ou le sous-réseau spécifique. Vérifiez que le mot de passe correspond en s’exécutant mysql -u myuser -p à partir du même réseau.

Erreur de base de données inconnue

Symptôme: DAB retourne Unknown database 'mydb' au démarrage.

Cause : La base de données spécifiée dans la chaîne de connexion n’a pas été créée sur le serveur MySQL.

Résolution: Créez la base de données avant de démarrer DAB en exécutant CREATE DATABASE mydb; l’interpréteur de commandes MySQL. Si vous utilisez un conteneur, définissez la MYSQL_DATABASE variable d’environnement afin que MySQL crée la base de données au premier démarrage.

Avertissement de type de colonne non pris en charge

Symptôme: DAB enregistre un avertissement concernant un type de colonne non pris en charge et le champ est manquant dans le schéma généré.

Cause : Certains types spécifiques à MySQL, tels que SET, ENUMou les types spatiaux, peuvent ne pas avoir de mappage direct dans le système de type DAB.

Résolution: Passez en revue les journaux DAB pour identifier la colonne et le type. Envisagez de modifier la colonne en un type pris en charge, comme VARCHAR pour les champs ENUM, ou d’exclure la colonne de la définition d’entité à l’aide de la configuration mappings afin de l’omettre du schéma exposé.

La mise à jour échoue sur les vues

Symptôme: Une requête PUT ou PATCH sur une entité sauvegardée par une vue MySQL échoue avec une erreur ou n’a aucun effet.

Cause : Le générateur d’API de données ne prend actuellement pas en charge les opérations de mise à jour sur les vues MySQL. Il s’agit d’une limitation connue suivie dans le problème GitHub #938.

Résolution: Utilisez une entité de table de base pour les opérations d’écriture. Si la vue est en lecture seule par conception, définissez « update » : false dans les autorisations de l’entité pour rendre la limitation explicite.

La mise à jour échoue sur les tables avec des colonnes calculées

Symptôme: Une requête PUT ou PATCH sur une table MySQL qui contient des colonnes calculées échoue ou retourne une erreur.

Cause : Le générateur d’API de données ne gère pas correctement les colonnes calculées pendant les opérations de mise à jour dans MySQL. Il s’agit d’une limitation connue suivie dans le problème GitHub #1001.

Résolution: Il n’existe aucune solution de contournement pour l’instant. Excluez les colonnes calculées des mappages de l’entité si possible, ou évitez les opérations de mise à jour sur les entités affectées jusqu’à ce que le problème soit résolu.

Le filtrage imbriqué n’est pas pris en charge

Symptôme: Une requête REST \ ou GraphQL ilter qui filtre sur un champ d’entité associé retourne une erreur ou des résultats inattendus sur une entité mySQL sauvegardée.

Cause : Le générateur d’API de données ne prend actuellement pas en charge le filtrage imbriqué pour MySQL. Il s’agit d’une limitation connue suivie dans le problème GitHub #1019.

Résolution: Appliquez le filtrage uniquement sur les champs d’entité de niveau supérieur. Pour les données imbriquées, récupérez le parent et filtrez côté client, ou restructurez la requête pour éviter les prédicats imbriqués.

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

Symptôme: La configuration d’une procédure stockée MySQL 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 MySQL. Il s’agit d’une limitation connue suivie dans le problème GitHub #1024.

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

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 MySQL n’est pas encore implémentée. Il s’agit d’une limitation connue suivie dans le problème GitHub #1329.

Résolution: Utilisez des autorisations basées sur des rôles pour restreindre l'accès à la création jusqu'à ce que la prise en charge de la stratégie de base de données pour la création MySQL 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é MySQL 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 MySQL n’est pas encore implémentée. Il s’agit d’une limitation connue suivie dans le problème GitHub #1371.

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 de la stratégie de base de données pour les opérations de mise à jour MySQL 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 sauvegardée par MySQL é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 MySQL 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 pour MySQL. 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.