Couchbase Lite .Net object models


I have recently began using Couchbase Server and Couchbase Lite. I am sold on document databases and your killer sync features.

That being said, it seemed to be easy to work with C# objects when working directly with the bucket, as per the Customer360 WebAPI lab, but not near as smooth working directly with the Couchbase Lite in .Net. Specifically, the bucket (Couchbase.NetClient) and the document (Couchbase.Lite) capabilities are pretty disparate.

I started to build a small serializer/deserializer using reflection as a POC and it looks like I could go that route but I see various references to to methods coming in 2.1 which would work more directly with c# objects. Do you have an idea of when and how that would work? Would the .Lite methodology become more like the .NetClient? Is there a roadmap somewhere of features to come?

Thank you very much,

Where? No such features are planned for 2.1.

I have an idea of how, but not when. If this is important to you, I’d try getting in touch with @ssmotra

@ssmotra or @daniel.petersen would have the answer to that

Like @borrrden, I’m not sure what methods your are referring to. Can you tell us what you are looking for and then we can let you know roughly if/when we’re adding them.


Thank you for your quick replies.

Here are a half dozen definitive references for you. I did look at the forums for quite some time before asking anything.

Really, all I want to know is there anything coming down the pipe that makes it as easier to add stuff to the local database in a manner more like adding something directly to a bucket? Or, is there a relatively simple method of turning a c# object into a mutabledocument? Or, do I just need to bite the bullet and write some code that takes classes and assembles a document?

I know I might be missing something, but if you can point me in the right direction, or if there is anybody in the community that is already doing this or can answer the question, it would be greatly appreciated.

Thank you very much,

March 2016

November 2016 - specifically mentioned by you, borrrden

January 2017 - jens talks about object modelling being in CBL 2.0

February 2017 - direct serialization of c# classes in 2.0 mentioned by you

May 2017 - planned feature of data modelling instead of laborious methods mentioned by you

September 2017 - specifically mentioned by jens as being pushed to 2.1

Yes, it has been mentioned many times on the forums and it is certainly a feature that I want to add! However, it hasn’t been officially scheduled yet. Over the years since then I’ve learned that I should be a lot more careful about how to word things. To be clear about the current state of affairs though:

  1. There is no way to currently auto map a class to a document
  2. This functionality is not being actively developed and is not scheduled for any future release.

Lol. Yeah, I have to be careful what I say at work too sometimes! Thanks for the replies. I’ll roll up something to make my life easier. I just didn’t want to put a whole lot of work into something if it wasn’t going to be necessary.

Thanks again! I’ve been wanting to get back to document storage ever since we got rid of lotus notes. :slightly_smiling_face:

Not sure if you are using CBLite 1.4 or 2.0.

We’re using 1.4, and basically JSON.NET is your friend if you want to convert to/from a strongly typed object using the CBLite properties dictionary.


One disadvantage of using strongly typed objects with CBL is the issue of versioning and ensuring that all of your devices (and server-side code for that matter) are all referencing the exact same version of the type.

If you have some devices using a newer version of the object which contains more (or changed) properties, and that document gets synced to a device that is referencing an older version of that type, then you risk losing data during deserialization and subsequent serialization and saving of that document. This is where accessing the properties directly and having lots of helpers to cast to various primitive types is helpful.

It’s a different approach for sure, but it at least protects you from data loss.

I haven’t used 2.0 yet, so I don’t know what that model looks like.

I didn’t know about the FromObject API. That could be useful in the future for other things to. To comment on 1.x vs 2.x, I haven’t tested this but you could probably achieve the same thing directly from the document, which itself implements IEnumerable<KeyValuePair<string, object>> or at least by getting a dictionary out of it by calling ToDictionary() on it. With those values I imagine you should be able to take the same approach.

I just got on board so have only started to use 2.0. You have made a really good point there about versions and losing data, one that I didn’t even think about. Especially considering that my main reason for wanting to use Couchbase it is a flexible schema. Thank you very much and I’ll look into your approaches and also what @borrrden is talking above as well.

Thank you both very much