Entity Framework avec MySQL - Le délai d'expiration a expiré lors de la génération du modèle

edmgen entity-framework mysql

Question

J'ai construit une base de données dans MySQL et j'essaye de la mapper avec Entity Framework, mais je commence à courir avec "GenerateSSDLException" chaque fois que j'essaie d'ajouter plus de 20 tables au contexte EF.

Une exception de type 'Microsoft.Data.Entity.Design.VisualStudio.ModelWizard.Engine.ModelBuilderEngine + GenerateSSDLException' s'est produite lors de la tentative de mise à jour à partir de la base de données. Le message d'exception est le suivant: 'Une erreur s'est produite lors de l'exécution de la définition de la commande. Voir l'exception interne pour plus de détails.'

Erreur fatale rencontrée lors de l'exécution de la commande.

Le délai d'attente a expiré. Le délai d'attente écoulé avant la fin de l'opération ou le serveur ne répond pas.

Il n'y a rien de spécial dans les tables affectées, et ce ne sont jamais les mêmes tables, c'est simplement qu'après qu'un certain nombre de tables (non spécifique) a été ajouté, le contexte ne peut plus être mis à jour sans l'erreur "Timeout expired". Parfois, il ne reste qu'une table et parfois trois; les résultats sont assez imprévisibles. De plus, la variance dans le nombre de tables pouvant être ajoutées avant l'erreur nous indique que le problème réside peut-être dans la taille de la requête générée pour mettre à jour le contexte, qui inclut à la fois les définitions de table existantes et les nouvelles tables y sont ajoutés. Essentiellement, la requête SQL devient trop volumineuse et ne parvient pas à s'exécuter pour une raison quelconque.

Si je génère le modèle avec EdmGen2, cela fonctionne sans erreur, mais le fichier EDMX généré ne peut pas être mis à jour dans Visual Studio sans générer l'exception susmentionnée.

Selon toute vraisemblance, la source de ce problème réside dans l'outil de Visual Studio étant donné qu'EdmGen2 fonctionne correctement, mais j'espère que d'autres pourront peut-être donner des conseils sur la façon d'aborder ce problème très particulier, car il semble que je ne le suis pas. la seule personne qui en fait l'expérience .

Une suggestion proposée par un collègue était de maintenir deux fichiers EBMX séparés avec un croisement de table, mais cela me semble être une très mauvaise solution. Je suppose que c’est ce que j’obtiens en essayant d’utiliser la "nouvelle technologie". :(

Réponse acceptée

Je viens d'avoir mal à la tête sur ce problème dans tout l'après-midi. Cependant, j'ai trouvé la solution selon laquelle vous pouvez simplement ajouter une déclaration dans app.config ou web.config où votre connexion EF desinger existe sous la forme "Délai de commande par défaut = 300000;". Le problème est parti.


Réponse populaire

Le conseil ci-dessus n'est pas correct.

Default Command Timeout est le seul paramètre de chaîne de connexion que vous devez modifier. Connect Time régule simplement le temps d'attente pour obtenir une connexion en premier lieu; ce n'est pas ton problème.

Default Command Timeout semble n'avoir aucun effet dans la chaîne de connexion avec Connector / Net 6.3.4. Je pense qu'il s'agit d'un bogue dans Connector / Net et j'ai déposé un rapport de bogue auprès d'Oracle. EDIT: Ce bogue a été reconnu par les développeurs MySql et a été corrigé le 13/10/2010. Les correctifs ont été mis à 6.0.8, 6.1.6, 6.2.5 et 6.3.5.

La seule façon pour moi de contourner ce ObjectContext été de changer la propriété CommandTimeout de mon objet ObjectContext en autre que null. Si elle est nulle, elle est supposée utiliser la valeur du "fournisseur sous-jacent" par MSDN. S'il n'est pas nul, il s'agit de la valeur faisant autorité pour le nombre de secondes avant l'expiration du délai.

Par exemple:

var context = new CitationData.de_rawEntities();
context.CommandTimeout = 180;


Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow