[BUG] collection.UpdateMany stores property with DbRef inline instead of as reference

[rklfss]

Version
5.0.15

Describe the bug
When using the UpdateMany method on a collection, properties that are marked as DbRef are not stored as reference, but inline.

Code to Reproduce

using LiteDB;

var path = Path.Join(Path.GetTempPath(), "TestDbRef.db");

using var db = new LiteDatabase($"Filename={path};Connection=shared");

var b1 = new B
{
    Id = 1,
};

var b2 = new B
{
    Id = 2,
};

var a1 = new A
{
    Id = 11,
    Bref = b1,
};

db.GetCollection<B>().Upsert(b1);
db.GetCollection<B>().Upsert(b2);
db.GetCollection<A>().Upsert(a1);

// a1 = { "_id": 11, "Bref": { "$id": 1, "$ref": "B" } }

// Update now fails

db.GetCollection<A>()
    .UpdateMany(
        x => new A
        {
            Id = x.Id,
            Bref = b2,
        },
        x => x.Id == 11);

// a1 = { "_id": 11, "Bref": { "_id": 2 } }

// Subsequent selects fail, because the property is not stored as expected.

class A
{
    [BsonId]
    public int Id { get; set; }

    [BsonRef]
    public B? Bref { get; set; }
}

class B
{
    [BsonId]
    public int Id { get; set; }
}

Expected behavior
The translation of the expression consideres the DbRef mapping and stores references with { $id, $ref }.

Additional context
Tracked this down a bit and assume a point in LinqExpressionVisitor.VisitConstant. Here the Serialize method is called on the type of the object itself (here B) instead of the member of our collection type (here Bref of A). Guess the mapper instructions of the collection type should be evaluated everywhere, because this is the type that is expected from the update expression.

[JKamsker]

Does this happen with prerelease aswell? https://www.nuget.org/packages/LiteDB/6.0.0-prerelease.75

[rklfss]

Yes, the issue still exists.

[rklfss]

Tried to provide some contribution for that and figured out, this is not trivial.

Not sure within the ExpressionVisitor when there is actually the need to apply the DbRef serialization, because you can define things in an expression that may not make sense but are valid.

For example:

class B
{
    [BsonId]
    public int Id { get; set; }
    
    public string Name { get; set; }
}

db.GetCollection<A>()
    .UpdateMany(
        x => new A
        {
            Id = x.Id,
            Bref = new B // Valid, but not a constant anymore
            {
                Id = 100,
                Name = x.Bref.Name + "_foobar", // Valid, but actually not needed for Ref -> What is the expectation?
            },
        },
        x => x.Id == 11);

Apart form the not so useful property assignments, having such an inline new B expression, creates a BSON like
{ _id: @p0, Bref: { $id: @p1, Name: ($.Bref.Name + @p2) } }. So there is no point in using a serialize method around something like this, because the instance of B is not a constant.

The idea is maybe to provide some sort of "just for expressions" helper to achieve this.
Like:

public sealed class BsonRefId<T>
{
    public BsonRefId(BsonValue id)
    {
        Id = id;
    }

    internal BsonValue Id { get; }

    public static implicit operator T(BsonRefId<T> _) => throw new NotSupportedException("Just for Expressions");
}

With a custom ITypeResolver and the possibility to write

db.GetCollection<A>()
    .UpdateMany(
        x => new A
        {
            Id = x.Id,
            Bref = new BsonRefId<B>(100), // or new BsonRefId<B>(x.Id + 100)
        },
        x => x.Id == 11);

This would have a valid type to say exactly "I want the ref here" and also has the possibility to provide the ID only, as this is the only thing needed and usually the only thing provided by some DTO and therefor may make a lookup obsolete. Instead of 100 there could also be an expression. Maybe makes sense, maybe not, but it would be valid and is not the responsibility of the library.

You would get { _id: @p0, Bref: { $id: @p1, $ref: @p2 } } or { _id: @p0, Bref: { $id: ($._id + @p1), $ref: @p2 } }, which should be fine.

Not sure what you think about this? For the future, expression helpers (that do not have an actual implementation) could be helpful in other ways, too, for example to provide a way to use db functions that do not have a direct representation in code.