SG release notes

Deprecation Notices

The following features are being deprecated and will be unsupported in an upcoming version of Sync Gateway.

Bucket shadowing has been deprecated since 1.4 and has now become unsupported. The recommended approach to perform operations on a bucket dedicated to Couchbase Mobile is to enable shared bucket access.

New Features

No Conflicts Mode

Sync Gateway 2.0 can be run in "no conflicts mode". When running in this mode, Sync Gateway will reject any updates that would otherwise create a conflict.
When using Couchbase Lite 2.0, these conflicts can be automatically detected and resolved by the client.

Data Lifecycle Management

An expiry value can now be set for Couchbase Lite replication checkpoints (and local documents more generally), allowing users to configure how long these are retained.
By default they will be retained for 90 days, but this can be customized using (databases.$db.local_doc_expiry_secs).

Document expiry can now be set using the Sync Function.
A new built-in function, (expiry()) can be used to set the Couchbase Server expiry for the document.

Upgrading

Starting in Sync Gateway 2.0, Sync Gateway’s design documents include the version number in the design document name.
In this release for example, the design documents are named \_design/sync_gateway_2.0 and \_design/sync_housekeeping_2.0.

On startup, Sync Gateway will check for the existence of these design documents, and only attempt to create them if they do not already exist.
Then, Sync Gateway will wait until views are available and indexed before starting to serve requests.
To evaluate this, Sync Gateway will issue a stale=false&limit=1 query against the Sync Gateway views (channels, access and role_access).

If the view request exceeds the default timeout of 75s (which would be expected when indexing large buckets), Sync Gateway will log additional messages and retry.
The logging output will look like this:

Sync Gateway 2.0 will not automatically remove the previous design documents.
Removal of the obsolete design documents is done via a call to the new /_post_upgrade endpoint in Sync Gateway’s Admin REST API.
This endpoint can be run in preview mode (?preview=true) to see which design documents would be removed.
To summarize, the steps to perform an upgrade to Sync Gateway 2.0 are:

Upgrade one node in the cluster to 2.0, and wait for it to be reachable via the REST API (for example at http://localhost:4985/).

Upgrade the rest of the nodes in the cluster.

Clean up obsolete views:

Optional Issue a call to /_post_upgrade?preview=true on any node to preview which design documents will be removed. To upgrade to 2.0, expect to see "sync_gateway" and "sync_housekeeping" listed.

Issue a call to /_post_upgrade to remove the obsolete design documents. The response should indicate that "sync_gateway" and "sync_housekeeping" were removed.