Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query: Pay your (technical) debt on time #18923

Open
46 of 64 tasks
Tracked by #30173 ...
smitpatel opened this issue Nov 15, 2019 · 2 comments
Open
46 of 64 tasks
Tracked by #30173 ...

Query: Pay your (technical) debt on time #18923

smitpatel opened this issue Nov 15, 2019 · 2 comments
Assignees
Milestone

Comments

@smitpatel
Copy link
Contributor

smitpatel commented Nov 15, 2019

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.

@smitpatel smitpatel self-assigned this Nov 15, 2019
@ajcvickers ajcvickers added this to the 5.0.0 milestone Nov 15, 2019
smitpatel added a commit that referenced this issue Feb 6, 2020
Part of #9914

With shared entity types query root can no longer be identified using just type.

Part of #18923
smitpatel added a commit that referenced this issue Feb 6, 2020
Part of #9914

With shared entity types query root can no longer be identified using just type.

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 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
…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
smitpatel added a commit that referenced this issue Mar 31, 2020
Resolves #15080
Implemented behavior:
- If any part of composite key is null then key is null.
- If comparing entity with null then check if "any" key value is null.
- If comparing entity with non-null then check if "all" key values are non null.

Resolves #20344
Resolves #19431
Resolves #13568
Resolves #13655
Since we already convert property access to nullable, if entity from client is null, make key value as null.

Resolves #19676
Clr type mismatch between proxy type and entity type is ignored.

Resolves #20164
Rewrites entity equality during translation

Part of #18923
smitpatel added a commit that referenced this issue Apr 1, 2020
Part of #18923

Resolves #20155
Resolves #20369
We convert Queryable.Contains to Queryable.Any after navigation expansion has run so only true queraybles would have Queryable.Contains. Array properties would have Enumerable.Contains hence does not get rewritten.

Resolves #19433
smitpatel added a commit that referenced this issue Apr 1, 2020
Part of #18923

Resolves #20155
Resolves #20369
We convert Queryable.Contains to Queryable.Any after navigation expansion has run so only true queraybles would have Queryable.Contains. Array properties would have Enumerable.Contains hence does not get rewritten.

Resolves #19433
smitpatel added a commit that referenced this issue Apr 1, 2020
Part of #18923

Resolves #20155
Resolves #20369
We convert Queryable.Contains to Queryable.Any after navigation expansion has run so only true queraybles would have Queryable.Contains. Array properties would have Enumerable.Contains hence does not get rewritten.

Resolves #19433
@smitpatel
Copy link
Contributor Author

Consider refactoring in cosmos similar to #21181

@smitpatel
Copy link
Contributor Author

#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.
Ideally this is not necessary

  • The hash code computation of SelectExpression will figure out mismatch Tables through SelectExpression.Tables
  • If graph is consistent then a particular column expression would only come from a particular table.
    I tried to apply solution that ColumnExpression can be compared with just reference but it caused test failure.
    A solution where column expression are created from a fixed place of reference could resolve the issue as no 2 similar column expression instance would be generated. Things to keep in mind for that is all the places which can create column expression should not create one if there is already generated one. MakeNullable would be a bottleneck.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants