[CSHARP-4727] IFindFluent.Project on a single field always returns null Created: 18/Jul/23  Updated: 26/Jul/23  Resolved: 25/Jul/23

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 2.19.1, 2.20.0
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Shiya Kohn Assignee: Robert Stam
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File image-2023-07-25-15-21-23-352.png    
Issue Links:
Duplicate
duplicates CSHARP-4666 Support projecting a single field wit... Closed
Documentation Changes Summary:

1. What would you like to communicate to the user about this feature?
2. Would you like the user to see examples of the syntax and/or executable code and its output?
3. Which versions of the driver/connector does this apply to?


 Description   

Summary

When using IMongoCollection<T>` to do a find and project a property from a document, the resulting data will be null,

Versions

As far as I can tell, this starts in 2.19.x, this affects the Linq V3 adapter only.

How to Reproduce

Start by defining a schema, example:

 

class Point { 

     public int X { get; set; }

      ^      ^public int Y { get; set; }

}

Then create an IMongoCollection<Point>(omitting this for brevity), the following code is where things start getting weird.

If I do a simple .Find(...).ToList(), the results will be properly serialized into points exactly as I entered them, however, try to project just X or just Y, and you'll get the default values (0 in this case).

Example code

collection.Find(point => point.X == 90).Project(point => point.X).ToList()

Regardless of  your data, this will return a list of 0s. The underlying query is correctly formatted into something like "find({ "X" : 90 }, { "_v" : "$X", "_id" : 0 })", however, the results are missing the actual X points.



 Comments   
Comment by Robert Stam [ 26/Jul/23 ]

I have created CSHARP-4731 to track the issue of assigning a List<T> value to an IList<T> property.

But I'm not linking this ticket as related to that one because that is a completely separate issue.

Thanks for reporting that issue.

p.s. Assigning a List<T> value to an IList<T> property didn't work in LINQ2 either, so this is a new issue instead of a regression.

Comment by Robert Stam [ 26/Jul/23 ]

I don't see how CSHARP-4650 is related to this ticket. We don't yet have a fix for CSHARP-4650. Please follow that ticket for future updates.

Comment by Shiya Kohn [ 25/Jul/23 ]

I found the related issue https://jira.mongodb.org/browse/CSHARP-4650

 

Not fixed yet (as of 2.20.x), can you confirm whether it'll be fixed in the next release

Comment by Robert Stam [ 25/Jul/23 ]

Thanks for the additional information. I will attempt to reproduce the issue with `IList` and find out what the current status is. If the issue still exists I will create a Jira ticket for it. I appreciate your help!

Comment by Shiya Kohn [ 25/Jul/23 ]

I apologize for the mistake, the server I tested against wasn't our primary server that's running 4.4.6 but an older one.

 

I can confirm that all issues except number 4 are patched by now. I don't want to open a new issue since it's very hard to tell if there are already issues for that.

 

Let me know if you're aware of this issue or if I should open one

 

 

 

Comment by Robert Stam [ 25/Jul/23 ]

As for the other issues you mention, I am sorry you were affected by them. As you can imagine a LINQ provider is a pretty big project. We released LINQ3 as an opt-in provider for almost a year before making it the default. During that time we fixed issues that were reported against it. But once it became the default more users began using it and discovered issues that were not revealed during the opt-in period.

If you are still affected by any issues could you please create a separate Jira ticket for each one? Thanks!

Comment by Robert Stam [ 25/Jul/23 ]

I am unable to reproduce a problem with projecting a single field with server version 4.4.6. Here's my test:

[Theory]
[ParameterAttributeData]
public void Find_with_project_single_field_should_work(
    [Values(LinqProvider.V2, LinqProvider.V3)] LinqProvider linqProvider)
{
    var collection = GetCollection(linqProvider);
 
    var find = collection
        .Find("{}")
        .Project(x => x.X);
 
    var projection = TranslateFindProjection(collection, find);
    if (linqProvider == LinqProvider.V2)
    {
        projection.Should().Be("{ X : 1, _id : 0 }");
    }
    else
    {
        projection.Should().Be("{ _v : '$X', _id : 0 }");
    }
 
    var result = find.Single();
    result.Should().Be(1);
}
 
private IMongoCollection<C> GetCollection(LinqProvider linqProvider)
{
    var collection = GetCollection<C>("test", linqProvider);
    CreateCollection(
        collection,
        new C { Id = 1, X = 1 });
    return collection;
}
 
private class C
{
    public int Id { get; set; }
    public int X { get; set; }
}

I ran this test using commit 4aadc9f64decb55d24fefe72e0fbccf135d49de5 of the driver, which is the commit just before CSHARP-4666 was committed.

Are you sure you can reproduce this issue with server 4.4.6? If so, can you help me reproduce it?

Comment by Shiya Kohn [ 25/Jul/23 ]

Hi Robert.

 

This issue is not limited to older server versions. We're using 4.4.6.

 

As far as that other commenter goes, while I dislike their tone, I agree with the general complaint.

 

V3 was released with a breaking changes, and no documentation about it. As we were trying to update, we encountered four critical bugs.

 

  1. `ContainsKey` didn't work inside queries. It should be translated to an $exists query
  2. Support for [-1]was briefly removed before being patched
  3. The current projection bug
  4. We have properties that are defined as `List<T>` when projecting them into a new model where the same property is defined as `IList<T>` it doesn't work (I don't know whether this has been addressed, waiting for the next release to see)

 

Additionally, support for OData was broken briefly.

 

Support for `SelectMany(x => x)` ($unwind), which was required in the V2-adapter for aggregations, was removed without notice.

 

Not to mention that support for deserializing into `object` using `_t` discriminators was removed (security reasons, probably needed for dealing with untrusted data, ours isn't untrusted) without proper guidance on how to resolve (we had to dig deep to find the override).

 

This is too much for something being used in production for years. While V2 had plenty problems, we knew of them and accounted for them. Releasing a new version like this, without a release document listing breaking changes, is unacceptable.

 

That is not to knock on the library as a whole, on the contrary, I've read and learned a lot from your source code. I'm genuinely impressed by some of the translation components.

Comment by Robert Stam [ 25/Jul/23 ]

Thank you for your comment. We have thousands of tests, but unfortunately did not have a test for this particular case (we do now).

Keep in mind also that this issue only occurs if you are using a very old version of the server (prior to 4.4).

Comment by Inclouds N/A [ 25/Jul/23 ]

Projection on a single field is not a rare case at all. Don't you have any tests in your code? I cannot comprehend how publicly exposed api can introduce that kind of bugs, easy to detect with couple of tests.  

Comment by Robert Stam [ 18/Jul/23 ]

Thank you for reporting this. This is a duplicate of CSHARP-4666 which has already been fixed. The fix will be in the next release.

Comment by PM Bot [ 18/Jul/23 ]

Hi skohn@goflow.com, thank you for reporting this issue! The team will look into it and get back to you soon.

Generated at Wed Feb 07 21:49:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.