I did a test before Christmas using a very slightly modified NEventStore with Mongo persistence routed to DocumentDB. Everything worked fine at the time, now after Christmas something is awry. I wrote a test to isolate the problem and it appears that when persisting a long value (with the expectation it is serialized as an Int64, it is written as an Int32).
I can't figure out what has changed. Perhaps it is my code, or has Microsoft done something "under the hood"?
I tried the code below. The two connection strings alternate between the local "real" Mongo 3.4 server and the DocumentDB with Mongo support in Azure. I added the mongocsharprdriver version 1.10.0 (the one I used before Christmas) and then the very latest and no runtime difference was found.
The code below writes the long as an Int32 in DocumentDb, but as a long in the local MongoDB.
using System;
using System.Linq;
using System.Security.Authentication;
using MongoDB.Bson;
using MongoDB.Driver;
using MongoDB.Driver.Builders;
using MongoDB.Driver.Linq;
namespace DocumentDb.Mongo.Test
{
internal class Program
{
static void Main()
{
const string connectionString = @"mongodb://<my Azure MongoDB DocumentDB connection>/?ssl=true&sslverifycertificate=false";
// const string connectionString = @"mongodb://localhost:27017/test";
const string indexName = "_id";
var clientSettings = MongoClientSettings.FromUrl(new MongoUrl(connectionString));
clientSettings.SslSettings = new SslSettings() { EnabledSslProtocols = SslProtocols.Tls12 };
var client = new MongoClient(clientSettings);
var db = client.GetServer().GetDatabase("test");
var collection = db.GetCollection("testcollection");
const long testValue = 1;
var doc = new BsonDocument
{
{indexName, testValue}
};
collection.Update(
Query.EQ(indexName, testValue),
Update.Replace(doc),
UpdateFlags.Upsert);
doc = collection.AsQueryable().First();
Console.WriteLine($"Value={doc[indexName].AsInt64}");
}
}
}
No comments:
Post a Comment