Tener un poco de problemas para entender de palabra clave en LINQ

Question

1)

en la palabra clave crea identificador temporal para almacenar los resultados de unirse, grupo o seleccionar cláusulas.

Asumo into palabra clave sólo puede ser utilizado como parte del grupo , se unen o seleccionar las cláusulas?

2)

a) He leído que cuando into se utiliza como parte del grupo o seleccione cláusulas, que empalma la consulta en dos mitades y debido a que las variables de rango declarado en la primera la mitad de la consulta SIEMPRE sale del alcance en la segunda mitad de la consulta. ¿Correcto?

b) Pero cuando into se utiliza como parte de la unirse a la cláusula, las variables rangle nunca salen del alcance dentro de la consulta (a menos que la consulta también contiene group...into o select...into). Supongo que esto se debe a que into no empalma la consulta en dos mitades cuando se usa con join cláusula?

c) una expresión de consulta consiste en una de cláusula seguido de cuerpo de la consulta opcional (, en dónde, deja cláusulas) y debe terminar con cualquiera seleccionar de grupo cláusula.

d) Si into hecho empalmes de consulta en dos mitades, se encuentra en el siguiente ejemplo grupo cláusula forma parte del cuerpo:

 var result = from c1 in a1 
        group c1 by c1.name into GroupResult 
        select ... 

gracias

Responder al Ufuk:

una)

Después de un grupo se obtiene mediante una secuencia de esta manera IEnumerable>

no un operador de GroupBy devolver un resultado de tipo IEnumerable<IGrouping<Key,Foo>> y no IEnumerable<Key,IEnumerable<Foo>>

b) ¿No podríamos argumentar que group...by...into o join...into empalman la consulta en un sentido que la primera mitad de la consulta, al menos conceptualmente, debe ejecutarse antes de que se ejecute la segunda mitad de la consulta?

Responder a Robotsushi:

cuanto más pienso en ello, más me da la sensación de que mi pregunta es bastante inútil ya que no tiene valor práctico lo que nunca. Aún así ...

Cuando dices que se divide. Qué quiere decir el alcance de las variables consigue dividir o la consulta SQL generada se divide

Esta es la cita:

En muchos casos, las variables de rango en un lado de esta distancia no pueden ser mezclado con las variables de rango en el otro lado. La palabra clave into que forma parte de esta cláusula group-by se utiliza para vincular o empalmar dos mitades de esta consulta. Como tal, marca el límite en el medio de la consulta sobre la cual las variables de rango típicamente no pueden escalar. Las variables de rango encima de la palabra clave into están fuera del alcance en la última parte de esta consulta.

Mi pregunta es si ambas mitades todavía se consideran una sola consulta y, como tal, toda la consulta todavía consta de solo tres partes. Si ese es el caso, entonces en mi ejemplo de código (en d) la cláusula de grupo es parte del cuerpo. Pero si las dos mitades se consideran dos consultas, a continuación, cada una de las dos consultas constará de tres partes

2. respuesta a Robotsushi:

se evalúa Esta parte de su consulta como una extracción de datos.

No estoy familiarizado con el término "extracción de datos", así que voy a adivinar que lo que estaba tratando de decir es que la primera mitad de la consulta se ejecuta/evalúa como una unidad, y luego la mitad de la consulta toma los resultados de la primera mitad y usa los resultados en su ejecución/evaluación? En otras palabras, conceptualmente tenemos dos consultas?

Answer 1

grupo ... por ... en

Un group by tiene que proporcionar un tipo diferente de secuencia después de la operación.

Usted tiene una secuencia de la siguiente manera:

IEnumerable<Foo> 

Después de un grupo se obtiene mediante una secuencia de esta manera

IEnumerable<Key,IEnumerable<Foo>> 

Ahora sus artículos están en secuencias anidadas y que no tienen directa acceso a ellos Es por eso que los identificadores en la primera parte están fuera del alcance. Como su primera parte está fuera del alcance, se le deja el identificador después del en. Ha terminado y puede comenzar una nueva consulta. La segunda parte de la consulta funciona en una secuencia totalmente diferente de la primera. Es una continuación.

from foo in foolist 
group foo by foo.name into grouped 
//foo is out of scope, you are working on a different sequence now 
//and you have a ready to use range variable for your second query 

unen ... en ... en

Por otro lado, el grupo de unión no es ese tipo de operation.They operar en dos secuencias en las que el grupo opera por sobre uno. Proporcionarán elementos coincidentes en la secuencia correcta para la secuencia izquierda.

IEnumerable<Left> and IEnumerable<Right> 

Después de la operación que le permite utilizar el identificador de la secuencia de la izquierda, pero el identificador en la derecha está fuera de alcance. Eso es porque join devuelve una secuencia de ellos ahora. Entonces nuevamente no tienes acceso directo a ellos. El resultado de la unión de grupo es como:

IEnumerable<Left,IEnumerable<Right>> 

Cuando utiliza la unión de grupo, solo la variable de rango correcta sale del ámbito. Mientras que la parte izquierda aún permanece, todavía está trabajando en la misma secuencia. Aún no ha proporcionado una proyección, por lo que no puede continuar una segunda consulta.

from left in leftList 
join right from rightList 
    on left.Key equals right.Key into joinedRights 
// left is still your range variable, you are still enumerating leftList 
// you have to provide a projection here but you won't have a ready to use range variable 
// that's why it's not a continuation. 

Answer 2

1) corregir ... para ser más específico en proporciona una referencia a los resultados de una unión, grupo o cláusula de selección que estará fuera del alcance.

2) No creo que la consulta se divide como resultado del uso, ya que es en el uso es más comúnmente:

El uso de una cláusula en en grupo sólo es necesario cuando se quiere realizar operaciones de consulta adicionales en cada grupo

Agregado Respuesta

he leído que w la entrada se utiliza como parte de un grupo o selecciona cláusulas, empalma la consulta en dos mitades y debido a ese rango variables declaradas en la primera mitad de la consulta SIEMPRE quedan fuera del alcance en la segunda mitad de la consulta. ¿Correcto?

Este fragmento de su consulta se evalúa como una extracción de datos. La palabra clave de grupo requiere una operación de ordenación para continuar la evaluación de su LINQ consulta:

from c1 in a1 
group c1 by c1.name into GroupResult 

lo tanto, en la siguiente selecto:

seleccione ...

Las variables de la primera parte de la consulta se habría evaluado; sin embargo, dado que se incluye en la palabra clave, puede trabajar con los resultados de la consulta en la selección porque están almacenados en la variable GroupResult.

Sin embargo, cuando se utiliza en el marco de la cláusula de combinación, las variables rangle nunca salen del alcance dentro de la consulta (a menos de consultas también contiene grupo ... dentro o SELECT ... INTO). Supongo que esto se debe a que no empalma la consulta en dos mitades cuando se usa con cláusula join.

La consulta todavía se evalúa en dos partes sin embargo el GroupResult le da acceso a lo declarado antes de que el grupo palabra clave.

una expresión de consulta consiste en una cláusula from seguido de cuerpo opcional consulta (de, en donde, dejar cláusulas) y debe terminar con seleccionar de la cláusula grupo.

Esta es una definición no es una pregunta.

Si en efecto, empalmes consulta en dos mitades, es de la siguiente ejemplo parte cláusula grupo del cuerpo:

El grupo es parte de la primera mitad de la consulta.

Esta consulta LINQ mostrada generaría una instrucción sql en caso de que tuviera curiosidad.

segunda actualización

no estoy familiarizado con el término "tirón de datos", así que voy a adivinar que lo que estaba tratando de decir es que la primera mitad de la consulta ejecuta/evalúa como una unidad, y luego la segunda mitad de la consulta toma los resultados de la primera mitad y utiliza los resultados en su ejecución/evaluación ? En otras palabras, conceptualmente tenemos dos consultas ?

Sí, hay dos partes diferentes de la consulta.