Camel Case Convention Issues

[danielfishr]

I've spotted two related issues.

Persisted field names in the Commit collection respect registered MongoDB conventions, however the field names in the Commit collection's indexes do not.

I think the cause of this is when creating indexes you have the field names hard coded as the TitleCase strings specified by MongoCommitFields

       Builders<BsonDocument>.IndexKeys
                           .Ascending(MongoCommitFields.BucketId)
                           .Ascending(MongoCommitFields.StreamId)
                           .Ascending(MongoCommitFields.CommitId),

If a camelCase convention pack is registered like so.

            var pack = new ConventionPack
                           {
                               new CamelCaseElementNameConvention(),
                           };
            ConventionRegistry.Register("camel case", pack, t => true);

The app will be in a broken state as the indexes mismatch with the persisted field names.

The second issue to be aware of this that the handling of the camelCase convention is a breaking change with version 5 of NEventStore. Version 5 would persist the fields outside of the payload in TitleCase and fields within the payload as camelCase like so.

{ 
    "_id" : NumberLong(1), 
    "CommitId" : BinData(4, "iv6i8gubRQizTgq3nNp2DA=="), 
    "CommitStamp" : ISODate("2018-07-15T21:01:08.234+0000"), 
    "Headers" : {
        "AggregateType" : "Scoreboard.Domain.Member"
    }, 
    "Events" : [
        {
            "StreamRevision" : NumberInt(1), 
            "Payload" : {
                "headers" : {

                }, 
                "body" : {

Is this a known an intended breaking change?

[AGiorgetti]

Hi, NEventStore V5.x used the 1.x version of the MongoDB Drivers, the way things were registered were different at the time. With the new COnvention Packs if extremely easy to override any registration made by the library itsels.

Thus when definig your Conventions it's not recommended to 'touch' the classes the NEventStore driver uses to persist its own data.

My recommendation, when registering your convention, is always to specify the namespaces to which those settings applies.

[AGiorgetti]

I double checked the old code, and the BsonDocument was constructed "by hand" in NEventStore v5.x. In V6 we introduced a new MongoCommit class so we could better customize some aspects of the mapping.

I've created a Test and decorated the MongoCommit with BsonElement attribute that specify the correct field names for each property.