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

Share optimizations between relational and non-relational providers #34152

Open
Tracked by #34524
ranma42 opened this issue Jul 3, 2024 · 4 comments
Open
Tracked by #34524

Share optimizations between relational and non-relational providers #34152

ranma42 opened this issue Jul 3, 2024 · 4 comments

Comments

@ranma42
Copy link
Contributor

ranma42 commented Jul 3, 2024

Many optimizations are not dependent on the specific provider or whether the underlying model is relational.

It would be convenient to have a way to share them across all of the relevant targets.
Currently this is not trivial, first of all because they operate on different types (see Microsoft.EntityFrameworkCore.Cosmos.Query.Internal.SqlExpression vs Microsoft.EntityFrameworkCore.Query.SqlExpressions.SqlExpression.

@ChrisJollyAU
Copy link
Contributor

As an extension to this, there are optimizations in the SearchConditionConvertingExpressionVisitor in Sql Server. These aren't necessarily Sql Server specific and could be moved higher up so that all (or at least more) providers get it by default. As a note they all worked straight out the box on EFCore.Jet

@roji
Copy link
Member

roji commented Oct 11, 2024

@ChrisJollyAU what optimizations are you thinking of? Can you open a separate issue with specifics?

@ChrisJollyAU
Copy link
Contributor

Its the optimizations on the binary and unary expressions (specially those that @ranma42 has done). Currently they are just for SQL Server, but other databases could benefit from having them as well.

@roji
Copy link
Member

roji commented Oct 11, 2024

@ChrisJollyAU as far as I know, the optimizations in SearchConditionConvertingExpressionVisitor really are specific to SQL Server, since only SQL Server has the (somewhat odd) distinction between search conditions (things that can appear in the WHERE clause) and binary/bit values. PostgreSQL, for example, just has a simple booleantype which can be both a column type and something that can appear in the WHERE clause.

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