Explicite ! non ?

La solution : Paramétrer le Command Timeout de l’object context …

Du coup, le temps d’exécution des commandes SQL passe à 90 secondes (au lieu des 30 secondes par défaut).

Pour information : il est conseillé de rendre cette valeur paramétrable (config)…

http://msdn.microsoft.com/fr-fr/library/system.data.objects.objectcontext.commandtimeout.aspx

Voilou !

ctx.ContextOptions.LazyLoadingEnabled = false;

var cmds =
ctx.Commande
.Include(« DetailCommande »)
.Where(cmd=>…filtre…)
.GroupBy(cmd=>cmd.date)
.OrderBy(cmd=>cmd.Key)
.FirstOrDefault();

Cette requête va me retourner la première commande par jour en fonction d’un filtre.
Qu’importe l’intérêt fonctionnel (certainement débile :p ), centrons nous sur le résultat :
L’include est royalement nié : aucun détail de commande n’est présent dans les éléments retournés, malgré la clause Include.

Une solution possible (mais il y en a d’autres) :

• Retourner les ids de commande concernés :
  var ids =
  ctx.Commande
  .Where(cmd => …filtre…)
  .GroupBy(cmd => cmd.date)
  .OrderBy(cmd => cmd.Key)
  .FirstOrDefault().Select(cmd => cmd.Id);
• Récupérer les commandes avec l’include :
  var cmds =
  ctx.Commande
  .Include(« DetailCommande »)
  .Where(cmd => ids.Contains(cmd.Id)).ToList();

  PS : le ToList est là pour forcer l’exécution (vu que le LazyLoading est à false)

Afin d?assurer la cohérence des mises à jour de la base de données, nous utilisons des objets ?TransactionScope?.

Lors de l?insertion (ou de la mise à jour) de plus de 3000 objets simultanément, nous avons rencontré des exceptions telles que
?La transaction associée à la connexion active est terminée mais n’a pas été supprimée. Pour pouvoir utiliser la transaction pour exécuter des instructions SQL vous devez la supprimer.?
ce que l?on peut traduire en
?The transaction associated with the current connection has completed but has not been disposed. The transaction must be disposed before the connection can be used to execute SQL statements.?
(merci http://www.unlocalize.com)

La solution demeure assez simple :

il suffit de passer de

à

Pour information : https://connect.microsoft.com/VisualStudio/feedback/details/564598/ef-connection-brokes-when-sending-large-amount-of-data-in-transactionscope#tabs

• un modèle Entity Framework au sein d’une couche d’accès aux données,
• des CLR UDF (user defined functions) permettant l’agrégation de données (comme SUM, AVG, etc).
  
  Pour information, ce sont des assemblies dot net injecté dans SQL Server permettant de disposer de fonctionnalités dot net appelable à partir de code SQL directement, comme si ces fonctions étaient natives à SQL Server),

Nous avons été confrontés à la nécessité de devoir utiliser ces CLR-UDF(disponibles en SQL mais, pas nativement en C#) d’agrégation dans la DAL de l’application, via les requêtes Linq sur le modèle EF.

Nativement… ce n’est pas possible.

Il faut modifier le cours des choses…

Recette :

• Modifier l’edmx pour ajouter la fonction
• Ajouter une classe particulière au sein du projet, pour permettre à Linq-EF de connaitre la fonction
• Utiliser la fonction dans les requêtes Linq-EF

Modification de l’EDMX

Voici les fonctions d’agrégations disponibles sous SQL Server :

Ouvrir l’edmx dans le designer, et appeler le menu contextuel pour mettre à jour le modèle, ajouter la fonction (située dans les procédures stoquées…), en jaune ci dessous…

Valider en cliquant sur Terminer.

Ouvrer l’Edmx à la main (éditeur XML), à la recherche des fonctions d’agrégation ajoutées (InterpWeightAvg et InterpWeightSum):

<Function Name="InterpWeightAvg" ReturnType="float" Aggregate="false" 
          BuiltIn="false" NiladicFunction="false" IsComposable="true" 
          ParameterTypeSemantics="AllowImplicitConversion" Schema="dbo">
	<Parameter Name="value" Type="float" Mode="In" />
</Function>
<Function Name="InterpWeightSum" ReturnType="float" Aggregate="false" 
          BuiltIn="false" NiladicFunction="false" IsComposable="true" 
          ParameterTypeSemantics="AllowImplicitConversion" Schema="dbo">
	<Parameter Name="value" Type="float" Mode="In" />
</Function>

<Function Name="InterpWeightAvg" ReturnType="float" Aggregate="true" 
          BuiltIn="false" NiladicFunction="false" IsComposable="true" 
          ParameterTypeSemantics="AllowImplicitConversion" Schema="dbo">
	<Parameter Name="value" Type="Collection(float)" Mode="In" />
</Function>
<Function Name="InterpWeightSum" ReturnType="float" Aggregate="true" 
          BuiltIn="false" NiladicFunction="false" IsComposable="true" 
          ParameterTypeSemantics="AllowImplicitConversion" Schema="dbo">
	<Parameter Name="value" Type="Collection(float)" Mode="In" />
</Function>

Ajout d’une classe de mapping sur la fonction

L’étape ultime consiste à créer une classe d’extension, sur les types manipulés pour permettre la liaison avec la fonction d’agrégation.

    public static class LinqAggregatesMapper
    {
        [EdmFunction("MyEntityModel.Store", "InterpWeightAvg")]
        public static double? InterpWeightAvg(this IEnumerable<double?> source)
        {
            throw new NotImplementedException("Direct calls are not supported.");
        }

        [EdmFunction("MyEntityModel.Store", "InterpWeightAvg")]
        public static double? InterpWeightAvg(this IEnumerable<double> source)
        {
            throw new NotImplementedException("Direct calls are not supported.");
        }

        [EdmFunction("MyEntityModel.Store", "InterpWeightSum")] 
        public static double? InterpWeightSum(this IEnumerable<double> source) 
        { 
            throw new NotImplementedException("Direct calls are not supported."); 
        }
       
        [EdmFunction("MyEntityModel.Store", "InterpWeightSum")] 
        public static double? InterpWeightSum(this IEnumerable<double> source) 
        { 
            throw new NotImplementedException("Direct calls are not supported."); 
        }



    }

J’attire votre attention sur les points suivants :

• La classe est statique (normal => classe d’extension),
• L’utilisation du mot clé “this” (normal => méthode d’extension),
• Chaque fonction est décorée par un attribut “EdmFunction”. Cet attribut précise en premier paramètre le chemin (namespace) de la fonction dans l’edmx (nom du contexte de données + Store => indique le SSDL), le second paramètre précise le nom de la fonction dans le SSDL,
• Chaque fonction est doublée : type nullable et non nullable (indispensable),

Utilisation de la fonction dans Linq-EF

Exemple d’utilisation dans notre code :

var result = context.DonneeDetaillees.Select(data => data.DureeFonctionnement).InterpolateAvg();

En ouvrant le SQL Profiler (mais on peut également utiliser l’intellitrace de Visual Studio), il devient possible de voir dans la requête SQL générée l’utilisation de la fonction.

Attention tout de même : nous avons noté que lors de mises à jour de l’Edmx par le designer de Visual Studio, il arrivait que notre modification manuelle de la fonction soit à nouveau ré écrite par le designer.

Bonne journée

Merci à l’équipe : Xavier et David.

Il semblerait qu?un disfonctionnement vienne parfois troubler la sérialisation du modèle contenu dans l’ edmx.

Hier soir (mais qu’importe, cela ne change pas le problème ), nous avons tenté la mise à jour du modèle.

Et, comment ??? mais qu’est ce que j’apprends ??!

… pas très explicite …

Après recherche dans l’edmx , partie mapping (msl, merci Mme Julie Lerman pour votre beau livre), je note un noeud dupliqué : (merci Mr Altova pour votre magnifique XmlSpy)

Je supprime les lignes doublonnées, et relance la mise à jour du modèle et BINGO ! ca marche !

Résultat des courses :

Le designer construit l’edmx de façon incrémentielle, sans refactoriser les données par types (l’ordre d’apparition des noeuds enfant dans les parties CSDL, MSL et SSDL est fonction des mises à jour du modèle)

Le designer ne vérifie pas (toujours) si dans l’EDMX une notion existe déjà, ce qui peut entrainer le bug que nous avons eu.

En cas d’apparition du bug, la seule solution consiste à se palucher l’edmx à la manno ! (dans notre cas 75 classes, et le reste qui va avec -> héritage, x tables pour une classe, etc – )

Bon à savoir !

PS : Hormis cela, EF4 est une belle bête, qui demeure fiable !

Re PS : merci David pour ton aide dans l’analyse de l’edmx… nous n’avions pas trop de 2 paires d’yeux !

@+

WCF RIA Services nous permet de requêter, de façon quasi transparente, une source de données depuis une application cliente Silverlight (par exemple).

La syntaxe utilisée consiste à appeler Load de l’objet DomainContext instancié et de lui préciser quelle query utiliser.

Ce mécanisme suffit largement pour des filtrages basiques.

Lorsque l’on a à utiliser des filtrage plus complexes, RIA se trouve vite à bout de souffle.

Pour les exemples ci dessous, nous considérons que nous disposons du modèle de données suivant (Entity Framework par exemple) :
Une voiture contient 0-n roues,
Les roues ne sont pas retournées par défaut avec les voitures sur le client (via RIA).

Exemple de situation complexe :

   1: var monDomainCtx = new VehiculeDomainSrv();

   2: var query = monDomainCtx.GetVoitureQuery().Where(

   3:     voiture => voiture.Roues.Any(roue=>roue.IsAPlat));

   4:  

   5: monDomainCtx.Load<Voiture>(

   6:     query,

   7:     loadOp=>

   8:     {

   9:         ... // opération de chargement des voitures à pneu plat

  10:     },

  11:     false);

Nous tentons ici (côté client), de demander à RIA d’aller rechercher toutes les voiture qui ont (au moins) un pneu crevé (sous requête).

Dans ce cas de figure (présence d’une ou plusieurs sous requête), RIA va nous renvoyer une exception dont le message parlera d’une impossibilité d’utiliser Any (mais ce serait la même chose pour Count, First, etc).

La solution :

Dans le DomainServices (donc sur le serveur), nous allons implémenter une méthode décorée de l’attribut « System.Web.DomainServices.QueryAttribute ». Nous implémentons donc nos propres query !

Cette méthode retournera donc un objet IQueryable (au même titre que celles fournies par défaut : GetVoitureQuery() )

   1: [Query()]

   2: public IQueryable<Voiture> GetFiltreVoitures(Boolean roueCrevee)

   3: {

   4:     // création de la query de base retournéà partir du DataModel

   5:     var dataCtx = new GarageLocationDataModel();

   6:     

   7:     return dataCtx.Voiture.Where(voit => voit.Roue.Any(roue => roue.IsAPlat));

   8: }

Lors de l’exécution, nous utiliserons le code suivant (côté client)

   1: var dataCtx = new VehiculeDomainSrv();

   2:  

   3: dataCtx.Load<Vehicule>(

   4:     dataCtx.GetFiltreVoiture(true),

   5:     loadOp=>

   6:     {

   7:         // Corps de méthode pour récupérer les résultats

   8:         ...

   9:     },

  10:     false);

Le client ne fait que demander l’exécution de la query, cette dernière sera bien entendu exécutée (physiquement) sur le serveur.

Petite précision sur les méthodes Query :

Il faut noter une petite restriction concernant les paramètres des query : il n’est pas possible (à ce jour) de passer en paramètre un objet d’un type qui encapsule tous les critères de recherche (exemple : CritereVehicule).

En effet, les seuls types autorisés par RIA comme paramètre de query sont les classes qui héritent d’EntityObject et les types simples.

Nous sommes donc “forcés” de lier les couches fortement (pour le moment).

Exemple : nous désirons supprimer des objets en cascade (suppression d’une commande, qui implique la suppression des lignes de commandes, qui implique …).

Cette suppression sera plus rapide si son exécution est confiée au moteur de base de données, plutôt que par des appels multiples sur un contexte EF.

D’où la création d’une procédure stoquée, et son intégration au sein d’EF.

Lorsque l’on désire exploiter les procédures stoquées au sein d’EF, il suffit de passer par une "Function Imports" mappée sur la procédure référencée au préalable dans EF.

Si cette dernière un objet déjà exploité par EF, aucun problème : la méthode liée à la procédure est dynamiquement générée dans le contexte EF lors de la création de la fonction EF.
Par contre, lorsqu’il s’agit de retourner un type simple ou void : la méthode n’est pas générée…

Dans ce cas de figure, il faut donc "mettre les mains dans le moteur".

Pour ce faire, voici les étapes :

1. Créez votre procédure stoquée (qui ne retourne rien…),
   
2. Dans Visual Studio, ouvrez l’edmx, et sur le schéma, cliquez droit (menu contextuel), sélectionnez "Update Model From database" (voir ci dessous)
   
   

3. Dans l’écran de synchronisation du modèle Entity Framework, déployez Stored Procedure et sélectionnez celle à "injecter" comme fonction dans Entity Framework, et validez…
   
   

4. Ouvrez le Model Browser, et dans la partie qui concerne la description de la base de données utilisée par EF, déployez Store Procedure. Click droit sur celle qui nous intéresse et sélectionnez "Create Function Import"
   
    
   (ce qui est grisé est le nom du datamodel du projet)

5. Cela entraine l’ouverture de l’écran de paramétrage de la fonction.
   Ecran dans lequel, nous pouvons ajouter des précisions concernant la fonction (donc son nom).

    

   Passé ce stade ci, si le type de retour avait été Entity (un objet géré par EF), il aurait généré le code permettant l’appel de la fonction.

   Pour vérifier qu’il a bien enregistré la fonction : ouvrez le Model Browser, et déployer la partie entity jusqu’aux fonctions :

    

6. Créez une classe partielle portant le même nom, et même namespace que le contexte entity de votre modèle de données.

   PS : Pour connaitre le nom de la classe :

   • ouvrez l’edmx
   • cliquez sur l’arrière plan
   • F4 pour ouvrir l’écran de propriétés
   • reprenez le nom de la propriété "Entity Container Name"
     
     

   Re-PS : Pour connaitre le chemin du namespace de la classe :
   
   Ouvrez le fichier .cs lié à l’edmx, et copiez le namespace en tête de fichier.

   Maintenant que vous disposez du nom complet de la classe (namespace + nom de classe), vous pouvez créer une classe qui va porter le même nom, même namespace, mais avec le mot clé partial. &#160; <br />

      1: namespace MonNamespaceEF  

      2: {    

      3:     using System;    

      4:     using System.Collections.Generic;    

      5:     using System.Linq;    

      6:     using System.Text;      

      7:  

      8:     public partial class MainDataModel    

      9:     {        

     10:     }  

     11: }  

7. Dernière étape : le code permettant d’exploiter EF par "l’intérieur".

   Avant de montrer le code, une petite explication.

   Entity Framework est une couche de type DAL (couche permettant les accès aux données + le mapping relationnel objet).
   
   Étant donné qu’EF est conçu pour pouvoir fonctionner sur plusieurs sources de données (SQL Server, ou autre), il offre à l’utilisateur ses propres implémentations de DbConnection, DbCommand, etc afin de garder cette indépendance.
   Donc, dans le code exposé ci dessous, nous n’utilisons ni d’OleDb, ni de SQLClient mais bien EntityConnection, EntityCommand, etc.

      1: namespace ClassLibrary1

      2: {

      3:     using System;

      4:     using System.Collections.Generic;

      5:     using System.Linq;

      6:     using System.Text;

      7:     using System.Data.EntityClient;

      8:  

      9:     public partial class MainDataModel

     10:     {

     11:         /// <summary> 

     12:         /// Supprime une machine en profondeur (impacte toutes les tables liées) 

     13:         /// </summary> 

     14:         /// <param name="idGamme">The id gamme.</param> 

     15:         public void DeleteMachineDeep(String codeMachine)

     16:         {

     17:             // Crée une connection à partir de la cnnStr du datacontext 

     18:             using (EntityConnection conn = new EntityConnection(this.Connection.ConnectionString))

     19:             {

     20:                 try

     21:                 {

     22:                     EntityCommand cmd = conn.CreateCommand(); // crée une EntityCommand 

     23:  

     24:                     // CommandText correspond au nom de la fonction d'import (au sens Entity) 

     25:                     // le format d'identification est 'ContainerName.Stored Proc Name'  

     26:                     cmd.CommandText = String.Format("{0}.{1}", this.DefaultContainerName, "SUPPR_MACHINE");

     27:  

     28:                     cmd.CommandType = System.Data.CommandType.StoredProcedure;

     29:                     cmd.Parameters.AddWithValue("codeMachine", codeMachine); // ajout du param 

     30:  

     31:                     conn.Open();

     32:  

     33:                     cmd.ExecuteNonQuery();

     34:                 }

     35:                 catch (Exception)

     36:                 {

     37:                     conn.Close();

     38:                     throw; // renvoi l'exception pour traitement, 

     39:                 }

     40:             }

     41:         }

     42:     }

     43: }

8. L’utilisation :

      1: ...    

      2: var dataCtx = new MainDataModel();    

      3: dataCtx.DeleteMachineDeep("ST1236");  

      4:  ...  

Avant de conclure, je souhaite revenir sur un point important : le fait qu’EF utilise des types d’objets de manipulation de source de données indépendant des implémentations réelle (EntityCommand, EntityConnection, etc) prouve qu’il a été conçu pour être exploité de façon indépendante du type de moteur de base de données sur lequel il s’appuie (et ce proprement).

@+