efcore icon indicating copy to clipboard operation
efcore copied to clipboard

Share optimizations between relational and non-relational providers

Open ranma42 opened this issue 1 year ago • 4 comments

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.

ranma42 avatar Jul 03 '24 17:07 ranma42

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

ChrisJollyAU avatar Oct 11 '24 15:10 ChrisJollyAU

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

roji avatar Oct 11 '24 16:10 roji

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.

ChrisJollyAU avatar Oct 11 '24 16:10 ChrisJollyAU

@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.

roji avatar Oct 11 '24 18:10 roji