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