-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Query: Pay your (technical) debt on time #18923
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Open
46 of 64 tasks
Labels
area-groupby
area-query
composite-issue
A grouping of multiple related issues into one issue
ef6-parity
type-enhancement
Milestone
Comments
smitpatel
added a commit
that referenced
this issue
Feb 12, 2020
Introduces QueryableMethodNormalizingExpressionVisitor which - Extract query metadata methods - Convert from enumerable to queryable - Convert List.Contains to queryable Contains - Flatten GroupJoin-SelectMany Nav expansion now calls this method on query filter/ defining query Resolves #19708 Part of #18923
smitpatel
added a commit
that referenced
this issue
Feb 12, 2020
Introduces QueryableMethodNormalizingExpressionVisitor which - Extract query metadata methods - Convert from enumerable to queryable - Convert List.Contains to queryable Contains - Flatten GroupJoin-SelectMany Nav expansion now calls this method on query filter/ defining query Resolves #19708 Part of #18923
smitpatel
added a commit
that referenced
this issue
Feb 27, 2020
This change introduces derived types of EntityQueryable<T> to be processed as query root in core pipeline. Currently FromSql and Queryable functions generate a method call in query pipeline which would be mapped to a query root. This means that any visitor which need to detect query root, they have to have special code to handle this. With this change, any provider bringing custom query roots can inject custom query root for relevant subtree in the query and it would be processed transparently through the stack. Only during translation, once the custom query root needs to be intercepted to generate correct SQL. Converted FromSql in this PR. Will submit another PR to convert queryable functions. Custom query roots can be generated during query construction itself (before it reaches EF), such query root requires - Overriden Equals/GetHashCode methods so we differentiate them during query caching. - Optional ToString method for debugging print out. - Conversion to such custom roots in QueryFilter if needed. - Components of custom root cannot be parameterized in ParameterExtractingExpressionVisitor Part of #18923
smitpatel
added a commit
that referenced
this issue
Feb 27, 2020
This change introduces derived types of EntityQueryable<T> to be processed as query root in core pipeline. Currently FromSql and Queryable functions generate a method call in query pipeline which would be mapped to a query root. This means that any visitor which need to detect query root, they have to have special code to handle this. With this change, any provider bringing custom query roots can inject custom query root for relevant subtree in the query and it would be processed transparently through the stack. Only during translation, once the custom query root needs to be intercepted to generate correct SQL. Converted FromSql in this PR. Will submit another PR to convert queryable functions. Custom query roots can be generated during query construction itself (before it reaches EF), such query root requires - Overriden Equals/GetHashCode methods so we differentiate them during query caching. - Optional ToString method for debugging print out. - Conversion to such custom roots in QueryFilter if needed. - Components of custom root cannot be parameterized in ParameterExtractingExpressionVisitor Part of #18923
smitpatel
added a commit
that referenced
this issue
Feb 27, 2020
This change introduces derived types of EntityQueryable<T> to be processed as query root in core pipeline. Currently FromSql and Queryable functions generate a method call in query pipeline which would be mapped to a query root. This means that any visitor which need to detect query root, they have to have special code to handle this. With this change, any provider bringing custom query roots can inject custom query root for relevant subtree in the query and it would be processed transparently through the stack. Only during translation, once the custom query root needs to be intercepted to generate correct SQL. Converted FromSql in this PR. Will submit another PR to convert queryable functions. Custom query roots can be generated during query construction itself (before it reaches EF), such query root requires - Overriden Equals/GetHashCode methods so we differentiate them during query caching. - Optional ToString method for debugging print out. - Conversion to such custom roots in QueryFilter if needed. - Components of custom root cannot be parameterized in ParameterExtractingExpressionVisitor Part of #18923
smitpatel
added a commit
that referenced
this issue
Feb 27, 2020
This change introduces derived types of EntityQueryable<T> to be processed as query root in core pipeline. Currently FromSql and Queryable functions generate a method call in query pipeline which would be mapped to a query root. This means that any visitor which need to detect query root, they have to have special code to handle this. With this change, any provider bringing custom query roots can inject custom query root for relevant subtree in the query and it would be processed transparently through the stack. Only during translation, once the custom query root needs to be intercepted to generate correct SQL. Converted FromSql in this PR. Will submit another PR to convert queryable functions. Custom query roots can be generated during query construction itself (before it reaches EF), such query root requires - Overriden Equals/GetHashCode methods so we differentiate them during query caching. - Optional ToString method for debugging print out. - Conversion to such custom roots in QueryFilter if needed. - Components of custom root cannot be parameterized in ParameterExtractingExpressionVisitor Part of #18923
smitpatel
added a commit
that referenced
this issue
Mar 18, 2020
smitpatel
added a commit
that referenced
this issue
Mar 18, 2020
…minatorCondition If DiscriminatorCondition returns null for IEntityType then return null instance. Part of #18923
smitpatel
added a commit
that referenced
this issue
Mar 18, 2020
…minatorCondition If DiscriminatorCondition returns null for IEntityType then return null instance. Part of #18923
smitpatel
added a commit
that referenced
this issue
Mar 18, 2020
…minatorCondition If DiscriminatorCondition returns null for IEntityType then return null instance. Part of #18923
smitpatel
added a commit
that referenced
this issue
Mar 18, 2020
…minatorCondition If DiscriminatorCondition returns null for IEntityType then return null instance. Part of #18923
smitpatel
added a commit
that referenced
this issue
Mar 18, 2020
…minatorCondition If DiscriminatorCondition returns null for IEntityType then return null instance. Part of #18923
Consider refactoring in cosmos similar to #21181 |
#21700 causes slight regression and spike in memory usage just to compute hash code. Which leads into another rabbit hole that projection is mainly comprised of column expressions coming from tables and when computing their hash code we may go inside another select expression.
|
This was referenced Jul 21, 2020
Merged
8 tasks
23 tasks
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
area-groupby
area-query
composite-issue
A grouping of multiple related issues into one issue
ef6-parity
type-enhancement
This is a grouping of related issues. Feel free to vote (👍) for this issue to indicate that this is an area that you think we should spend time on, but consider also voting for individual issues for things you consider especially important.
Creating a general tracking issue for tasks which were deferred in new query pipeline due to time constraint and also as an iteration over the design as we see customer reports we are getting.
This is a meta issue. It will evolve and add more stuff as we discuss things in team meetings (like the one we did about null semantics & command caching). I would prefer this to be assigned to me as the sticky we decided in the planning process. And we will split out smaller tasks out of this and assign to actual implementer. If you are working on something already, please add tracking issue here next to the item.
Parameter extraction
Preprocessor
Translation
Postprocessor
ShaperCompiler
SqlProcessor
Command execution
Whole pipeline
The text was updated successfully, but these errors were encountered: