MongoDB Bson Serializer

[cmeyertons]

Describe the feature

Would you be open to adding an integration for MongoDB Bson serialization to the enum list of integrations?

I would be happy to help contribute this!

I was thinking we would support strongly typed serialization for the primitive types here and then default to object for any other type

[SteveDunn]

Hi @cmeyertons - adding MongoDB Bson support would be a fantastic addition! It would be great if you'd like to contribute this.

[SteveDunn]

Hi again @cmeyertons - is there any help you need in getting this working?

[cmeyertons]

@SteveDunn - i started working on the Orleans related support first to get started. Man, this solution is painful to build & navigate due to the huge amount of snapshots in the SnapshotTests project -- I ended up excluding those from the project via a globbing pattern and the DX is much nicer - do you have any thoughts one way or another on the manageability of the snapshots included in the VS project?

The other piece that seems to missing is an Integration Testing project that references the Vogen source generator and generates actual objects so that we can test integrations w/ other source generators. In the Orleans case, that's really critical to ensure that the Vogen plays nicely w/ the Orleans source generator

I'm trying to add a project to do so (this could include full Orleans tests that reference the Vogen project directly) but Visual Studio does not like the direct project reference in this solution

Been playing around w/ some ideas here but no luck so far...

[SteveDunn]

Hi, yes I completely agree that the developer experience is a pain due to all of the snapshot tests. The biggest and slowest culprit of these are the ones that do permutations of the different constituents, e.g. a internal/public record/struct/class/readonly struct with combinations of converters/serializers. All repeated for every framework because there's subtle differences in the behaviour of the hoisted methods.

It would be great if this pain could be eased somewhat, maybe by reducing the permutations and/or reducing the amount of frameworks that are supported. It's not only a bad DX, but it really slows down Git operations and builds take literally hours!

Re, the integration tests that reference Vogen; this is tricky because you can't directly access use the source generator in the source generator solution. There is another solution called Consumers.sln. What happens is that build.ps1 builds the generator, runs the tests, and spits out the NuGet package in a private folder. The package is version 999.9.xxx and the consumer references the latest version. The consumer can then really use the source generator, just like anything else.

Thanks for the feedback!

[fb-smit]

Hi @cmeyertons do you have any update on this?

[shupoval]

Hi @fb-smit, I did the following in my project.

public class BsonSerializerAdapter<TValue, TUnderlyingTypeValue>(
    IBsonSerializer<TUnderlyingTypeValue> serializer,
    Func<TValue, TUnderlyingTypeValue> to,
    Func<TUnderlyingTypeValue, TValue> from)
    : SerializerBase<TValue>
{
    public override TValue Deserialize(BsonDeserializationContext context, BsonDeserializationArgs args)
        => from.Invoke(serializer.Deserialize(context, args));

    public override void Serialize(BsonSerializationContext context, BsonSerializationArgs args, TValue value)
        => serializer.Serialize(context, args, to.Invoke(value));
}

P.S.
@SteveDunn, I highly appreciate your work for both Vogen and Intellenum. They are awesome!

[SteveDunn]

Thanks for info @shupoval - I'll take a look at incorporating that in. I'm very pleased to hear such great feedback on these projects - much appreciated!

[SteveDunn]

This will be in 4.0.16, hopefully in a day or so. Thanks all for your help with this!