[C#] from A in As from B in Bs from C in Cs en dynamic

Version imprimable

Bonjour,
j’aimerai pouvoir optimiser mes jointure faite dynamiquement,
en effet le code qui suit est quelque peu lent, ce qui nuit a l'utilisation du soft.
J'ai vu sur des forums qu'il était possible de faire de multiple inner join sur une même table de la façon suivante :

Code:

1
2
3
4
from A in As 
from B in Bs
from C in Cs
where A.ID == B.ID || A.ID == C.ID select A

J'aimerrai pouvoir faire de même mais de façon dynamique via une methode, laquelle je ne trouve pas.

Voici mon code de base que j'aimerrai optimiser :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
            IQueryable<Souscription> baseReq = req;
            req = null;
            foreach (var item in ModeSouscriptions)
            {
                if (item is ModeSouscriptionAgence)
                {
                    IQueryable<Souscription> souReq = from souscription in baseReq
                                                      join mode in Context.ModeSouscription.OfType<ModeSouscriptionAgence>()
                                                       on souscription.ModeSouscription_ModeSouscriptionID equals mode.ModeSouscriptionID
                                                      select souscription;
                    if (req == null)
                        req = souReq;
                    else
                        req = req.Union(souReq);
                }
                else if (item is ModeSouscriptionCourrier)
                {
                    IQueryable<Souscription> souReq = from souscription in baseReq
                                                      join mode in Context.ModeSouscription.OfType<ModeSouscriptionCourrier>()
                                                       on souscription.ModeSouscription_ModeSouscriptionID equals mode.ModeSouscriptionID
                                                      select souscription;
                    if (req == null)
                        req = souReq;
                    else
                        req = req.Union(souReq);
                }
}

Merci, a bientôt

08/04/2011, 08h53
iberserk

Peut'on voir la structure de vos tables?
08/04/2011, 08h54
iberserk

Citation:

en effet le code qui suit est quelque peu lent, ce qui nuit a l'utilisation du soft.

Evidemment vous faites des requêtes dans une boucle!
08/04/2011, 09h03
ostenhard
Bonjour,

Euh...

Quelle est l'utilité d'exécuter toujours la même requête (donc toujours le même résultat à chaque tour de boucle ?

Dans le code donné qu'est-ce qui change à chaque tour ?
- Item : qui n'est utilisé que pour son type
- req qui est alimenté par le union via les soureq
Essaye de retirer la boucle !

Merci de ces réponses,
je vais essayer de supprimer la boucle, mais étant donné que c'est de l'linq to entities, normalement la requette est exécuter uniquement quand j'utilise le IQueryable (donc la boucle ne pause pas de problème), le Union est une source d’exécution SQL croyez-vous ?
En générale je fais un ToList() après la construction de mon IQueryable pour exécuter ma requette en SQL.

Pour la structure de la table, j'utilise l'abstraction fourni par EF pour tester le type d'une classe abstraite (je trouve cela pas mal).

Je propose de filtrer selon les types dérivé de la classe de base qui elle est stocké dans une table comme un simple champ.
Donc pour filtrer je fait des jointures internes avec les tables des classe dérivés.
La liste de filtre est aléatoire , c'est pour cela que j'utilise une boucle.
Le problème de la jointure interne est que je suis obligé de faire un union pour joindre ma requette sur plusieurs table d'un même champ.

Voici une autre version, mais qui m'oblige a faire un Distinct en fin de requette ce qui réduit également les performances. Quand même moins que la version précèdent, mais c'est toujours pas ça.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 bool isModeSouscriptionAgence = false; bool isModeSouscriptionCourrier = false; bool isModeSouscriptionMail = false; foreach (var item in ModeSouscriptions) { if (item is ModeSouscriptionAgence) isModeSouscriptionAgence = true; else if (item is ModeSouscriptionCourrier) isModeSouscriptionCourrier = true; else if (item is ModeSouscriptionMail) isModeSouscriptionMail = true; } IQueryable<Souscription> req = from souscription in souscriptionSituations from modeSouscriptionAgence in Context.ModeSouscription.OfType<ModeSouscriptionAgence>() from modeSouscriptionCourrier in Context.ModeSouscription.OfType<ModeSouscriptionCourrier>() from modeSouscriptionMail in Context.ModeSouscription.OfType<ModeSouscriptionMail>() where (souscription.ModeSouscription_ModeSouscriptionID == modeSouscriptionAgence.ModeSouscriptionID && isModeSouscriptionAgence == true) || (souscription.ModeSouscription_ModeSouscriptionID == modeSouscriptionCourrier.ModeSouscriptionID && isModeSouscriptionCourrier == true) || (souscription.ModeSouscription_ModeSouscriptionID == modeSouscriptionMail.ModeSouscriptionID && isModeSouscriptionMail == true) select souscription; req.Distinct().ToList();
Quand je fait un test de performance 30% de l’exécution ce fait dans req.Distinct().ToList();
Merci.

08/04/2011, 14h24
iberserk

Peut'on voir la structure de vos tables?
08/04/2011, 14h35
neoncyber

Voici la structure de mes tables

http://data.imagup.com/6/1116931695.png

Citation:

Envoyé par neoncyber

je vais essayer de supprimer la boucle, mais étant donné que c'est de l'linq to entities, normalement la requette est exécuter uniquement quand j'utilise le IQueryable (donc la boucle ne pause pas de problème),

Les choses inutiles font perdre du temps en général après je ne connais pas le détail de la mécanique interne du linq to sql mais moi moins j'en fais moins ça me prend de temps !

Pour ça, je dirais que ça ne sert à rien :

Code:

1
2
3
4
5
6
7
8
9
   foreach (var item in ModeSouscriptions)
            {
                if (item is ModeSouscriptionAgence)
                    isModeSouscriptionAgence = true;
                else if (item is ModeSouscriptionCourrier)
                    isModeSouscriptionCourrier = true;
                else if (item is ModeSouscriptionMail)
                    isModeSouscriptionMail = true;
            }

Et pour la requête simplement ça, ça ne fonctionne pas ?

Code:

1
2
3
4
5
 
IQueryable<Souscription> req = from souscription in souscriptionSituations
                                           from modeSouscription in Context.ModeSouscription
                                           where (souscription.ModeSouscription_ModeSouscriptionID == modeSouscription.ModeSouscriptionID
                                 select souscription;

08/04/2011, 14h43
iberserk

Confirmez moi ce que vous voulez faire:
Vous avez trois tables (qui se retrouve être de l'heritage une fois dans ENTITIES) et en fonction de 3 booleans (j'image....) vous voulez retourner l'union des tables ?
08/04/2011, 14h45
iberserk

Citation:

Voici la structure de mes tables

Ce n'est pas une structure de table çà mais votre "modèle" LINQ TO ENTITIES :ccool:
08/04/2011, 14h55
neoncyber

http://data.imagup.com/6/1116933007.png

En français ce que je veux faire ce dirai,

Je veux toutes les souscriptions qui sont :
Faite par mail.
Faite par mail ou par agence.
Faite par mail ou par agence ou par courrier.
etc ...
Exactement comme un filtre excel (d'ailleur l'IHM ressemble a excel).

Pour ne pas utiliser d'enum qui me semble pas très correct en ORM, j'utilise
une classe de base ModeSouscription, cette classe de base est utilisé dans UN seul champ de la classe qui l'utilise (souscriptions) et cette classe de base peut avoir plusieur dérivation (agence, courrier etc)

C'est comme si souscription avait un champ enum qui peut contenir O,1,2

Sauf que la ce champ contient 0,1,2 qui sont les ID des classe dérivés de mode souscriptions, comme ca pas besoin de savoir ce que c'est 0,1,2, car il suffit de tester le type de la classe a qui appartient cette ID.
Pour tester le type en Linq au moment de la requette il faut faire un OfType.

C'est un peu compliqué a expliquer...

Je veux retourner l'union de trois resultat. Chaque resultat correspond a une liste de souscription de type derivé de modeSouscription.

Ok il faut que je retourne sur terre au lieu de parler de class etc, je vais faire un screen de mes tables SQL !
10/04/2011, 07h57
iberserk

Citation:

Pour ne pas utiliser d'enum qui me semble pas très correct en ORM, j'utilise

Donc vos trois tables ModeSouscription_ ne contiennent que ModeSouscriptionId???

Ces 3 tables n'ont pour moi pas vraiment lieu d'être et auraient pu être remplacés par des vues SQL.

Etant spécialisé base de données cela me fait bondir naturellement mais qu'en pensent les pro du pattern .NET?
10/04/2011, 12h09
Nathanael Marchand

A moins que le modèle soit plus complet après en rajoutant des champs différents dans chaque table ModeSouscription, une enum aurait été largement adaptée!

L'héritage n'est pas trop concu pour ce cas, c'est plutot "j'ai une entité Employee, Doctor et Nurse en héritent" et ca se modéliserait avec trois tables et un champ discriminant dans Employee. Et d'ailleurs, je suis pas sur qu'il soit possible d'obtenir une requete de l'union des Doctors et des Nurses dans le cas la...

Merci de vos réponse,
Finalement je me suis un peu pris la tête est fait un builder de requette en eSQL
qui permet de requetter une table selon les types dérivé d'un de ces champs.
Je ne connai pas les vus SQL c'est grave... (ca doit pas être très ORM j'espere)
Non mais vraiment a chaque foi que je vois un enum dans une base de donné sa me donne des boutons (peut être est-ce a cause de EF qui ne les gère pas encore correctement)
Par ailleur CodeFirst permet un meilleur requettage SQL sur les heritages, vue que tous est dans la même table pas besoin de faire de distinct (j'ai oublié pourquoi).

En gros mon eSQL fait des left join sur la classe ModeSouscription des different type, et fait un where pour selectionner uniquement ceux demandé...
(en code first ce serrai different)

Par ailleur un enum ne permet pas de faire des enum en arbre (comme de l'heritage).

Dans un project cela ma permis de rajouter un comportement a une valeur d'un enum en le dérivant encore. Ce qui evite de rajouter cette nouvelle valeur d'enum dans toute les close if etc...

Donc mon eSQL gère également l'expect pour des class sous dérivés,
par exemple (totalement bidon) on demande modesouscriptioncourriermaison mais pas modesouscriptioncourrier tous cours.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 
    public class FilterEntityType
    {
 
 
        public string getEntites( 
            List<Type> SelectFilterType,
            List<Type> ExpectFilterType, 
            string targetEntityCollection, 
            string baseFilterEntity,
            string targetEntityProprtyJoinID,
            string baseFilterEntityPropertyID,
            string namespaceBaseFilterEntity)
        {
            string joinQuerys = "";
 
            foreach (Type item in SelectFilterType)
            {
                joinQuerys += string.Format(
                    "LEFT OUTER JOIN OFTYPE({0}, {1}.{2}) AS {2}Selector ON target.{3} == {2}Selector.{4} ",
                    baseFilterEntity,
                    namespaceBaseFilterEntity,
                    item.Name,
                    targetEntityProprtyJoinID,
                    baseFilterEntityPropertyID);
            }
 
            string whereIns = whereIn(SelectFilterType, baseFilterEntityPropertyID);
 
 
            string notIn = "";
 
            foreach (Type item in ExpectFilterType)
            {
                notIn += string.Format("&& {0}Selector.{1} IS NULL ", item.Name, baseFilterEntityPropertyID);
            }
 
            string query = string.Format(
                "SELECT VALUE target FROM {0} AS target {1} WHERE target.{2} IN {{{3}}} {4}",
                targetEntityCollection,
                joinQuerys,
                targetEntityProprtyJoinID,
                whereIns,
                notIn
                );
            return query;
        }
        private string whereIn(List<Type> FilterType, string baseFilterEntityPropertyID)
        {
            string whereInQuerys = "";
 
            foreach (Type item in FilterType)
            {
                whereInQuerys += string.Format(
                    "{0}Selector.{1},",
                    item.Name,
                    baseFilterEntityPropertyID);
            }
            whereInQuerys = whereInQuerys.Remove(whereInQuerys.LastIndexOf(','));
 
            return whereInQuerys;
        } 
 
    }

Un exemple :

Code:

1
2
3
4
       SELECT VALUE souscription FROM Souscriptions AS souscription 
                LEFT OUTER JOIN OFTYPE(ModeSouscription,ConsoleApplication1.ModeSouscriptionCourrier) AS courrier ON souscription.ModeSouscription == courrier.Id 
                LEFT OUTER JOIN OFTYPE(ModeSouscription,ConsoleApplication1.ModeSouscriptionAgence) AS agence ON souscription.ModeSouscription == agence.Id 
                WHERE souscription.ModeSouscription_Id IN {agence.Id, courrier.Id}

A bientôt !

12/04/2011, 07h09
iberserk

Citation:

(ca doit pas être très ORM j'espere)

Je rêve...
Ce n'est pas une question d'être ORM ou pas (ce qui ne veut rien dire dailleurs...) c'est une question de faire les choses bien en se basant sur un langage (SQL) extrêmement normalisé...
12/04/2011, 07h11
iberserk

Citation:

Donc mon eSQL gère également l'expect pour des class sous dérivés,
par exemple (totalement bidon) on demande modesouscriptioncourriermaison mais pas modesouscriptioncourrier tous cours.

En bref une nouvelle usine à gaz pour rien du tout encore liée à une mauvaise modélisation...