ok j'ai besoin d'une vérification de la santé mentale ici ...
J'ai compilé une requête qui retourne une question qui retourne une question iquérissable lorsqu'elle est exécutée.
sur quelle ligne (s) la requête s'exécute réellement Contre la base de données dans l'exemple suivant? Voici comment je définis la requête compilée
5 Réponses :
"sur la ligne 104, lors de la conversion toliste."
Eh bien, cette réponse est incorrecte. Nous invoquons la déléguée stockée dans une variable myCompileDQuery sur la ligne 101 qui renvoie le résultat de la requête compilée, pas la requête elle-même.
Je pense que cette requête s'exécute réellement à la ligne 101 (même avant d'appeler Tolist).
La ligne 101 crée une requête. La requête est exécutée lorsque les données réelles sont récupérées.
Pas dans le cas d'une requête compilée, vérifiez via le code source de fournisseur LINQ 2 SQL. Pour une requête compilée, il frappe la ligne 101. Stackoverflow.com/Questtions/6592386/...
La question était de savoir quand la "requête s'exécute réellement contre la base de données" non lorsque le délégué est exécuté.
@Peter. Et ce délégué crée et exécute la requête. À l'origine, je pensais que cela en crée un. J'avais tort.
Il exécute à la ligne 104 (lorsque vous appelez Tolist ()).
Une requête compilée est une requête qui n'est traduite qu'une seule fois sur TSQL au moment de la compilation, au lieu de chaque fois avant l'exécution.
Vous avez raison, mais vous fractionnez les cheveux. La toliste est en ligne 104, pas 102. Ce n'est pas une question truc et il voulait savoir si la compilation de la requête signifie qu'il s'exécute immédiatement, et non la caisse des 3 lignes est une déclaration.
J'aimerais penser qu'il exécute à 102/104, mais lorsque j'exécute un débogueur et un profileur SQL, je vois une instruction SQL exécutée après 101 exécutes, puis 12 déclarations SQL (une pour chaque résultat sur 101) exécutée à 102 / 104
@Antilogic: Cela dépend de la façon dont vous avez écrit votre requête compilée, non? Si cela ne peut pas être différé, il s'exécutera immédiatement.
@Alan, voir le message original que j'ai mis à jour pour contenir un exemple de la requête compilée.
@Antilogic Vous pouvez voir ce comportement lors de l'exécution des déclarations d'un seul par un en débogueur. Exécutez les deux déclarations sans arrêt d'arrêt et voir combien de déclarations SQL ont été émises.
Au fait, j'espère que vous savez que la requête compilée n'est pas composable, vous recevez donc tous les enregistrements dans la mémoire, puis sélectionnez ceux avec ID> 5.
Je pense que cette requête s'exécute réellement à la ligne 101 (même avant d'appeler Tolist).
Vous ne pouvez pas définir un point d'arrêt à 104 simplement parce que le débogueur ne prend pas en charge Lambdas (et d'où les déclarations de Linq) L'appel à Tolist () invoque réellement la requête à la base de données; Le fait que vous ne puissiez pas définir un point d'arrêt sur la même ligne que la méthode Tolist () est hors de propos.
@Alex, il devrait envoyer la comparaison avec la base de données car vous utilisez le type iquéryable, pas iénumérable.
Ceci est appelé exécution différée.
Vous pouvez lire un bon post sur celui-ci ici .
Ouais c'est ce que je pensais et comment j'ai conçu ma candidature. Toutefois, lorsque l'application exécute la ligne 101, je vois une instruction SQL voler par SQL Profiler, puis une autre instruction SQL pour chaque résultat renvoyé par la ligne 101.
Je peux confirmer ce que l'antilogique posté. Query s'exécute sur la ligne 101
@Antilogic: le processus de compilation de la requête peut avoir besoin d'informations sur la structure de la base de données, mais elle n'atteint aucune donnée à ce stade. Si c'était le cas, cela ne ferait rien chercher plus tard lorsque vous utilisez le résultat.
Cette requête s'exécute sur la ligne 101. Je l'ai vérifiée en effectuant une trace de profileur SQL. Je suppose que c'est parce que c'est une requête compilée.
Le filtrage Vous faites des nouvelles mots> 5 est fait en mémoire.
-1 Vérifiez la trace à nouveau. Il pourrait y avoir du trafic si des informations sur la structure de la base de données sont nécessaires, mais la requête réelle n'est pas exécutée en la compilant. Cette page par exemple indique clairement que vous pouvez fournir des valeurs de paramètres après la compilation de la requête, ce qui ne serait pas possible si la requête a également été exécutée: msdn.microsoft.com/en-us/library/bb896297.aspx
Appeler la méthode de la requête compilée provoque l'exécution de la requête sur la base de données. Je l'ai vérifié plusieurs fois avec une base de données simple. Bien sûr, vous pouvez passer des valeurs de paramètre, je ne dis pas que la compilation le fait exécuter, je dis que l'appelant la méthode de la requête compilée le fait exécuter et pas la méthode .tolist ().
Autant que je sache que je sache que je ne suis jamais exécuté, il convertit simplement la requête Linq à un format requis pour qu'il soit exécuté chaque fois que sa demande.
Dans ce cas, je suppose que le moment est demandé de convertir en une liste qu'il interroge le résultat. Et aucun point dans la lutte à propos de la ligne 102 et 104, comme cela représente une seule ligne.