Query: reuse include pipeline for queries projecting uncomposed collection navigations #8584
Assignees
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Milestone
Comments
|
related to #8229 |
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => SuppressNavigationRewrite(prm?.Reference?.Collection)) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied).
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => SuppressNavigationRewrite(prm?.Reference?.Collection) ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied).
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => SuppressNavigationRewrite(prm?.Reference?.Collection) ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied).
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => SuppressNavigationRewrite(prm?.Reference?.Collection) ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied).
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => SuppressNavigationRewrite(prm?.Reference?.Collection) ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied).
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => SuppressNavigationRewrite(prm?.Reference?.Collection) ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied).
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 2, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 3, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 3, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 3, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 3, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 3, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
maumar
added a commit
that referenced
this issue
Jun 3, 2017
…ncomposed collection navigations
Currently when projecting collection navigation we produce N+1 queries. This change leverages include pipeline which produces 2 queries instead and joins the result on the client.
We only do this for collection navigation that are not composed on - otherwise, the query that happens after collection navigation would be performed on the client, so it's not clear that would be preferable to N+1.
Also as a side effect, we always materialize root entity (or all intermediate entities in case of multi-level navigation). This is a side effect of reusing Include pipeline, which always expects (and depends on) root element being materialized.
We leverage the include pipeline by performing a simple QM rewrite:
from [e] in entities
select new { [e].Id, [e].Reference.Collection }
will be translated to:
from [e] in entities
select new { [e].Id, _ProjectCollectionNavigation([e], prm => prm?.Reference?.Collection ?? new ICollection<Entity>()) }
additionally, we generate include result operator for [e].Reference.Collection.
When include pipeline processes the updated QM, it will apply the include on first argument to _ProjectCollectionNavigation.
Implementation of _ProjectCollectionNavigation simply invokes the Func specified as it's second argument (which accesses requested collection navigation), given the root entity (which now has include applied)
|
fixed in 0075cb7 |
maumar
added
the
closed-fixed
This was referenced Jun 3, 2017
thiennn
added a commit
to simplcommerce/SimplCommerce
that referenced
this issue
Jun 28, 2017
thiennn
added a commit
to simplcommerce/SimplCommerce
that referenced
this issue
Jul 6, 2017
* upgraded to netcore2preview2 * changed in ef core preview2 * ef core changed dotnet/efcore#8584 * correct user/role model remove Microsoft.VisualStudio.Web.CodeGeneration.Design from WebHost because of warnings * corret the type of select expression Expression<Func<TModel, TResult>> * remove redundant Includes * Remove PackageTargetFallback(deprecated) * update readme, dockerfile
bruslega
added a commit
to elsashop/SimplCommerce
that referenced
this issue
Aug 22, 2023
* upgraded to netcore2preview2 * changed in ef core preview2 * ef core changed dotnet/efcore#8584 * correct user/role model remove Microsoft.VisualStudio.Web.CodeGeneration.Design from WebHost because of warnings * corret the type of select expression Expression<Func<TModel, TResult>> * remove redundant Includes * Remove PackageTargetFallback(deprecated) * update readme, dockerfile
polarisjrex0406
added a commit
to polarisjrex0406/SimplCommerce
that referenced
this issue
Apr 19, 2024
* upgraded to netcore2preview2 * changed in ef core preview2 * ef core changed dotnet/efcore#8584 * correct user/role model remove Microsoft.VisualStudio.Web.CodeGeneration.Design from WebHost because of warnings * corret the type of select expression Expression<Func<TModel, TResult>> * remove redundant Includes * Remove PackageTargetFallback(deprecated) * update readme, dockerfile
auroravirtuoso
added a commit
to auroravirtuoso/e-commerce-system-dotnet
that referenced
this issue
Jul 7, 2024
* upgraded to netcore2preview2 * changed in ef core preview2 * ef core changed dotnet/efcore#8584 * correct user/role model remove Microsoft.VisualStudio.Web.CodeGeneration.Design from WebHost because of warnings * corret the type of select expression Expression<Func<TModel, TResult>> * remove redundant Includes * Remove PackageTargetFallback(deprecated) * update readme, dockerfile
frank-verynice
added a commit
to frank-verynice/e-commerce-system-dotnet
that referenced
this issue
Nov 29, 2024
* upgraded to netcore2preview2 * changed in ef core preview2 * ef core changed dotnet/efcore#8584 * correct user/role model remove Microsoft.VisualStudio.Web.CodeGeneration.Design from WebHost because of warnings * corret the type of select expression Expression<Func<TModel, TResult>> * remove redundant Includes * Remove PackageTargetFallback(deprecated) * update readme, dockerfile
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
currently produces N+1 queries, however, similar query:
is much better, producing only 2 queries.
We should be able to leverage the include pipeline for the first query
The text was updated successfully, but these errors were encountered: