Upgrade

On upgrading from a 2.x release, all Couchbase Lite databases will be automatically re-indexed on initial database open.
This can result in a delay before the database is usable.

3.2.1 Upgrade

The action will take place automatically and can lead to some delay in the database becoming available for use in your application.

In addition, if you are syncing with a 3.2.1 Sync Gateway, you should be aware of the significant configuration enhancements introduced and their impact. See Upgrading Sync Gateway for more details. This is a one-way conversion.

API Changes

This content introduces the changes made to the Couchbase Lite for C#.Net API for release 3.2.1.

Starting from this release Couchbase Lite for C#.Net requires Visual Studio 2019+ and uses .Net Core 3.1 (updating from .Net Core 2.0).

Breaking Change

The function ATAN2(x, y), which returns the principal value of the arc tangent of y/x, now becomes ATAN2(y, x); that is, the arguments are reversed in line with common notation.

Removed

Activate

We have removed the method Activate() from all platform support libraries except Support.Android (Xamarin Android)

EnableTextLogging()

We have removed the obsolete method EnableTextLogging() from all the platform support libraries.

ResetCheckpoint

The method ResetCheckpoint() has been removed. Use the reset: argument when starting the replicator instead.

Before

replicator.ResetCheckpoint();
replicator.Start();

After

replicator.Start(true) (1)

1	Set the `reset:` argument `true` to initiate a replicator checkpoint reset

SetLogLevel()

We have removed the method Database.setLogLevel()
Use Database.log.console instead:

Before

Database.SetLogLevel(LogDomain.Replicator, LogLevel.Verbose);
Database.SetLogLevel(LogDomain.Query, LogLevel.Verbose);

After

Database.Log.Console.Domains = LogDomain.All;
Database.Log.Console.LogLevel = LogLevel.Verbose;

Database.Compact

We have removed the method Database.compact().
Use the method Database.PerformMaintenance() and the enum MaintenanceType instead

Before

var db = new Database("thisdb");
db.Compact()

After

var db = new Database("thisdb");

db.PerformMaintenance(MaintenanceType.Compact)

Deprecated API

Match

We will remove Match at the next major release.
You should plan to switch to using the alternative FullTextFunction.match(indexName:) at the earliest opportunity.

Before

var whereClause =
        FullTextExpression.Index("nameFTSIndex").Match("'querystring'");
using (var query = QueryBuilder.Select(SelectResult.Expression(Meta.ID))
    .From(DataSource.Database(db))
    .Where(whereClause)) {
    foreach (var result in query.Execute()) {
        Console.WriteLine($"Document id {result.GetString(0)}");
    }
}

After

var whereClause =
      FullTextFunction.Match("nameFTSIndex"),"'querystring'"); (1)
using (var query =
    QueryBuilder.Select(SelectResult.Expression(Meta.ID))
      .From(DataSource.Database(db))
      .Where(whereClause)) {
      foreach (var result in query.Execute()) {
        Console.WriteLine($"Document id {result.GetString(0)}");
      }
  }

1	Here we use FullTextFunction.match(indexName:) to build the query

IsNullOrMissing

We will remove isNullOrMissing
You should plan to switch to using the alternative IsNotValued()

at the earliest opportunity.

Before

var query = QueryBuilder.Select(SelectResult.All())
    .From(DataSource.Database(db))
    .Where(Expression.Property("missingprop").IsNullOrMissing())

After

var query = QueryBuilder.Select(SelectResult.All())
    .From(DataSource.Database(db))
    .Where(Expression.Property("missingprop").IsNotValued())

NotNullOrMissing

We will remove notNullOrMissing.
You should plan to switch to using the alternative isValued() at the earliest opportunity.

| isNotValued()

Before

var query = QueryBuilder.Select(SelectResult.All())
    .From(DataSource.Database(db))
    .Where(Expression.Property("notmissingprop").NotNullOrMissing())

After

var query = QueryBuilder.Select(SelectResult.All())
    .From(DataSource.Database(db))
    .Where(Expression.Property("notmissingprop").IsValued())

1.x Databases Upgrades to 2.x

Databases created using Couchbase Lite 1.2 or later can still be used with Couchbase Lite 2.x; but will be automatically updated to the current 2.x version. This feature is only available for the default storage type (i.e., not a ForestDB database).

Encrypted Databases

The automatic migration feature does not support encrypted databases. So if the 1.x database is encrypted you will first need to disable encryption using the Couchbase Lite 1.x API (see the 1.x Database Guide).

Thus, to upgrade an encrypted 1.x database, you should do the following:

Upgrading Encrypted Databases

Disable encryption using the Couchbase Lite 1.x framework (see 1.x encryption guide)
Open the database file with encryption enabled using the Couchbase Lite 2.x framework.

Since it is not possible to package Couchbase Lite 1.x and Couchbase Lite 2.x in the same application this upgrade path would require two successive upgrades.

If you are using Sync Gateway to synchronize the database content, it may be preferable to run a pull replication from a new 2.x database with encryption enabled and delete the 1.x local database.

Handling of Existing Conflicts

If there are existing conflicts in the 1.x database, the automatic upgrade process copies the default winning revision to the new database and does NOT copy any conflicting revisions.

This functionality is related to the way conflicts are now being handled in Couchbase Lite — see Handling Data Conflicts.

Optionally, existing conflicts in the 1.x database can be resolved with the 1.x API prior to the database being upgraded.

Handling of Existing Attachments

Attachments persisted in a 1.x database are copied to the new database. NOTE: The relevant Couchbase Lite API is now called the Blob API not the Attachments API.

The functionally is identical but the internal schema for attachments has changed.

Blobs are stored anywhere in the document, just like other value types. Whereas in 1.x they were stored under the _attachments field.

The automatic upgrade functionality does not update the internal schema for attachments, so they remain accessible under the _attachments field. See Example 1 for how to retrieve an attachment that was created in a 1.x database with a 2.x API.

Example 1. Retrieve 1.x Attachment

var attachments = doc.GetDictionary("_attachments");
var avatar = attachments.GetBlob("avatar");
var content = avatar?.Content;

Replication Compatibility

The current replication protocol is not backwards compatible with the 1.x replication protocol. Therefore, to use replication with Couchbase Lite 2.x, the target Sync Gateway instance must also be upgraded to 2.x.

Sync Gateway 2.x will continue to accept clients that connect through the 1.x protocol.

It will automatically use the 1.x replication protocol when a Couchbase Lite 1.x client connects through http://localhost:4984/db and the 2.0 replication protocol when a Couchbase Lite 2.0 client connects through ws://localhost:4984/db.

This allows for a smoother transition to get all your user base onto a version of your application built with Couchbase Lite 2.x.

Visual Studio

The public facing API has completely changed in Couchbase Lite 2.0 and will require a re-write to upgrade an application that is using Couchbase Lite 1.x. To update an Xcode project built with Couchbase Lite 1.x:

Remove the existing Couchbase Lite nuget package from the Visual Studio project.
Remove all the Couchbase Lite 1.x dependencies — see the 1.x installation guide.
Install the Couchbase Lite 2.0 framework in your project — see Install. At this point, there will be many compiler warnings. Refer to the examples on this page to learn about the new API.
Build & run your application.

Downgrading Couchbase Lite

Downgrading Between Major Releases

No Downgrade Support - Downgrades between major versions of Couchbase Lite (CBL) are not supported. Once you upgrade to a new major version, downgrading to a previous major version may lead to incompatibility issues.

For example, Upgrading from CBL 2.x.x to CBL 3.x.x does not guarantee the ability to revert to CBL 2.x.x.

Downgrading Between Minor Releases

Conditional Downgrade Support - Downgrade support for minor releases is considered on a case-by-case basis. The release notes for each minor version will clarify whether downgrades are supported.

For example, if a new minor version such as CBL 3.1.0 is released the release notes will specify whether downgrading to CBL 3.0.x is supported.

Downgrading Between Patch Releases

Full Downgrade Support - Downgrades between patch releases are supported. Users can safely downgrade between different patch versions within the same minor release.

For example, if you’re running CBL 3.1.6 you can downgrade to CBL 3.1.4 or CBL 3.1.3 without issues.

How to . . .

Learn more . . .

Dive Deeper . . .

Mobile Forum | Blog | Tutorials

Upgrade

3.2.1 Upgrade

API Changes

Breaking Change

Removed

Activate

EnableTextLogging()

ResetCheckpoint

Before

After

SetLogLevel()

Before

After

Database.Compact

Before

After

Deprecated API

Match

Before

After

IsNullOrMissing

Before

After

NotNullOrMissing

Before

After

1.x Databases Upgrades to 2.x

Encrypted Databases

Handling of Existing Conflicts

Handling of Existing Attachments

Replication Compatibility

Visual Studio

Downgrading Couchbase Lite

Downgrading Between Major Releases

Downgrading Between Minor Releases

Downgrading Between Patch Releases

Related Content