ANN: Couchbase Lite 2.0 dev build #1 (for iOS/Mac/tvOS)

[Jens Alfke]

I’m very excited that we’ve just uploaded a first developer build of Couchbase Lite 2.0. [Docs] [Direct download]

“Developer Builds” are a new Couchbase program where we make available snapshots of work in progress — somewhere in between ‘nightly builds’ and a traditional alpha/beta preview release.  DBs [that acronym is not confusing at all] are built from commits that seem stable, but they haven’t been through formal QA. We plan to release one every few weeks.

You can read all about the DB1 release here. The key bullet points:

• We’ve learned from five years of experience and built a new cross-platform engine [LiteCore], and designed a new API.
• Performance is currently about six times as fast as 1.4 (on iOS), and we haven’t even started on serious optimization work yet.
• Querying uses a more familiar expression-based API, much like Core Data or LINQ, and is very compatible with the N1QL query language found on Couchbase Server.
• The Document API is easier to use, with mutable document properties. Native object modeling will be available on all platforms.
• Conflict handling is a lot easier: the library does the work of detecting conflicts and invokes your handlers to resolve them.

Since this is an early pre-alpha release, there are some serious limitations:

• Only runs on iOS, macOS and tvOS. We are working on other platforms; it looks like .NET will be the next available. Progress will be fast because most of the code is cross-platform (the Obj-C bindings are < 3k LOC.)
• Only the Objective-C API is available; we’re working on a native Swift API that will be a lot more idiomatic than the bridged classes.
• No replicator yet. 😫
• No REST API (Listener) yet.😭
• Some of the key document features — subdocuments and model objects — aren’t available yet.

We’re hard at work, and some of these should be resolved as early as DR2, coming in a few weeks; others will take longer, but obviously before the final release.

Even if you can’t yet work with this release, I recommend looking through the documentation or the API reference to get prepared for what’s coming.

If you have any questions or general feedback, feel free to post here (but start a new thread please.)

If you find bugs, please file them on Github; put “2.0” at the start of the title. Thanks!

—Jens

PS: One nice improvement specific to Apple platforms is that our source code now works better with CocoaPods and Carthage. So instead of downloading the binary, you can if you wish just add a line to a podspec or Cartfile and automatically build this release into an app. Instructions are in the README.

[dyowee]

I know there is no replicator yet, but please add support for bulk_get to CouchDB 2.0 :)

[Nick Wood]

In general, will Couchbase Lite 2.0 replication be compatible with CouchDB1/2 or will it be limited to Sync Gateway?

  Nick

[Thiago Alencar]

Nice work Jens! Gotta a small question for now, I read on the website about changes in the conflict resolution:

 (We will be providing canned conflict resolvers for common algorithms.)

I think it could be a nice idea to expand on that to include CRDT's. Have you thought about it? or is it the case that the current versioning model wouldn't fit to that approach ?

Best Regards,

Thiago

[Jens Alfke]

On Mar 4, 2017, at 4:47 PM, Thiago Alencar <thia...@gmail.com> wrote:

I think it could be a nice idea to expand on that to include CRDT's. Have you thought about it? or is it the case that the current versioning model wouldn't fit to that approach ?

Definitely thought about that! CRDTs* would generally be used for individual properties of documents, not as an entire document; so we’d need a resolve/merge API that can operate at the property level. Then you could build your doc’s conflict resolver out of pieces, so for example you could have most properties use a “last update wins” rule based on an updateTime property, except that the “votes” property is a counter CRDT, and the “comments” array should use a set union. We haven’t worked out what the API for this would look like, though.

—Jens

* https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type