tuespetre / impatient Goto Github PK

If you do something like this:

Users.SelectMany(u => u.Organizations).Where(o => o.Active).ToArray()

It results in a query like this:

SELECT * FROM Users

Instead of breaking it down into proper form.

This seems like an awesome project. However the example on the homepage doesn't really sell the point, because the original query isn't that bad.

Also for a library like this it would be beneficial to have benchmarks. Its really important to know if there are performance regressions (if any) or improvements.

dotnet/efcore#22525

check this case out

dotnet/efcore#22524

check this case out

Related:
dotnet/efcore#4021
dotnet/efcore#2282

In my vision, there should be an attribute let's say SqlJsonAttribute or whatever, that when we use it on an entity property, a string-based (e.g. nvarchar) column is created for it in the DB, and a HasConversion is added to the DbContext for that property instructing EF to transform its contents into JSON (whether it's a complex object, array or whatever), using the JSON serializer registered with the IDbContextServices/IDatabaseProviderServices fail-safing to JSON.NET.

A middleware will be injected to the EF runtime that intercepts the queries and rewrites all the parts that concern those jsonized properties into OPENJSON SQL queries, so that from the point of view of the layer using EF, no special attention has to paid when querying those properties as far as it concerns LINQ to SQL support.

Can compatibility be changed from netcoreapp2.1 to netstandard2.0 to match Microsoft.EntityFrameworkCore.SqlServer 2.1

public class Transaction
{
    public byte? type { get; set; }
}
var res1 = from t1 in dataContext.Table1TypeNotNull select new Transaction {type=t1.type}
var res2 = from t2 in dataContext.Table2TypeNullable select new Transaction {type=t2.type}
var resUnion = res1.Concat(res2);

I expected that resUnion should be a "Union" SQL but it is fallbacked to enumerable (execute 2 select separatly then make the union happen in memory)

The cause is that t1.type is (byte) and t2.type is (byte?)

I think that the rule is not reasonable, we would be able to generate a UNION query in my case...