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

Cosmos DB null handling bug #30586

Closed
HEBOS opened this issue Mar 27, 2023 · 2 comments
Closed

Cosmos DB null handling bug #30586

HEBOS opened this issue Mar 27, 2023 · 2 comments

Comments

@HEBOS
Copy link

HEBOS commented Mar 27, 2023

I'm not sure if this is by design, but it is clearly different when compared to relational database query.

Given the following model:

public class Order
{
    public Guid OrderId { get; set; }
    public Address Address { get; set; }
    public bool? Checked { get; set; }
    public string DistributionPointId { get; set; }
}

and incoming request:

request = {
  DistributionPointId = null
}

When we execute the following query

var query = context.Orders
            .Where(order => order.DistributionPointId == request.DistributionPointId &&  order.Checked == true);

We get it translated to

SELECT c FROM root c  WHERE ((c["Discriminator"] = "Order") AND (c["Checked"] = true))

It seems that DistributionPoint is left out of the equation, if the scalar value that we use to compare with, isn't provided.

Is that by design?


EF Core version:
Database provider: Microsoft.EntityFrameworkCore.Cosmos, 7.0.3
Target framework: .NET 7.0
Operating system: Windows 11
Visual Studio 2022 17.4.3

@ajcvickers
Copy link
Member

This issue is lacking enough information for us to be able to fully understand what is happening. Please attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.

@ajcvickers
Copy link
Member

We recommend against using the in-memory provider for testing--see Testing EF Core Applications. While we have no plans to remove the in-memory provider, we will not be adding any new features to this provider because we believe valuable development time is better spent in other areas. When feasible, we plan to still fix regressions in existing behavior.

@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Apr 11, 2023
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

2 participants