Announcing Couchbase Mobile 2.0 Beta 2 (DB 23)

Discussion:

Priya Rajagopal

2018-03-19 15:12:24 UTC

Happy to announce the release of Couchbase Mobile 2.0 Beta 2 which includes
Couchbase Lite 2.0 Beta 2 and Sync Gateway 2.0 Beta 2. NOTE that Couchbase
Lite 2.0 Beta 2 clients require Sync Gateway 2.0 Beta 2. Please refer to
the [Compatibility matrix ]
<https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=swift#compatibility-matrix> for
details.

You can download the latest Beta Build from our Downloads page under
âPre-Releaseâ versions : https://www.couchbase.com/downloads

The second beta release includes following major changes -
- Updates to behavior of SaveDocument API and automatic conflict resolution
policy. (Related [blog
<https://blog.couchbase.com/document-conflicts-couchbase-mobile/>] ).
- Encryption is moved out of 2.0 release
- Replication bug fixes and optimizations
- General performance improvements

We have two versions of the build now - Community Edition (CE) and an
Enterprise Edition (EE). Both editions are free to use for development
purposes. Enterprise edition has some stipulations when you go production.
- This is the [CE License]
<https://github.com/couchbase/couchbase-lite-net/blob/master/LICENSE>
- This is the [EE License]
<(https://info.couchbase.com/rs/302-GJY-034/images/2017-10-30_License_Agreement.pdf>

The Couchbase Lite 2.0 Beta release is available for iOS(Swift, ObjC),
.NET (UWP, Xamarin) and Android platforms . Xamarin will a CE only release
in 2.0.

***Links to platform specific release notes -***
- [Sync Gateway 2.0]
<https://developer.couchbase.com/documentation/mobile/2.0/references/sync-gateway/release-notes/index.html>
- [Swift/ObjC]
<https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=swift>
- [.Net]
<(https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=csharp>
- [Android]
<https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=java>

***Related Blogs :***
- [Introducing Queries in Couchbase Lite 2.0]
<https://blog.couchbase.com/sql-for-json-query-interface-couchbase-mobile/>
- [Introducing Full Text Search in Couchbase Lite 2.0]
<https://blog.couchbase.com/full-text-search-couchbase-mobile-2-0/>
- [Querying Array Collections in Lite]
<https://blog.couchbase.com/querying-array-collections-couchbase-mobile/>
- [Replication in Couchbase Mobile 2.0]
<https://blog.couchbase.com/data-replication-couchbase-mobile/>
- [Automatic Conflict Resolution in Couchbase Mobile 2.0]
<https://blog.couchbase.com/document-conflicts-couchbase-mobile/>
- [Join Queries in Couchbase Lite 2.0
<https://blog.couchbase.com/join-queries-couchbase-mobile/>]
- [Certificate Pinning in Android with Couchbase Mobile 2.0]
<https://blog.couchbase.com/certificate-pinning-android-with-couchbase-mobile/>

***Sample Apps :***
- ToDo App :
https://github.com/couchbaselabs/mobile-training-todo/tree/feature/2.0
- Travel Sample App : https://github.com/couchbaselabs/mobile-travel-sample

***About Couchbase Mobile 2.0:***

Couchbase Mobile 2.0 is a groundbreaking new release for Couchbase Mobile.
Key enhancements include a cross-platform common core, new and improved
Query API with Full-Text search capabilities, automatic conflict resolution
and a new web sockets based replication protocol

***About Beta Builds:***

Beta release is a way for you to test the latest functionality of a release
before it is generally available. These will eventually become production
releases with full support when they are stable and features are complete.

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/eb41e3e1-c99a-4567-9b2a-af2168650642%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ben Kennedy

2018-03-20 18:37:02 UTC

Permalink

I am extremely concerned about the changes to conflict resolution in 2.0,
as elucidated in the linked blog post.

In short, my understanding is that there is no longer any way for the
client to deal with conflicts arising from a pull replication (where a new
local revision conflicts with one delivered by Sync Gateway). This seems
like it will promise ongoing non-deterministic and silent data loss when
operating offline (or, indeed, when racing against other mobile clients
speaking to Sync Gateway). Really?

This issue is serious enough I wanted to raise it for clarification here
(despite having also posted a reply on the blog post).

-ben

Post by Priya Rajagopal
Happy to announce the release of Couchbase Mobile 2.0 Beta 2 which
includes Couchbase Lite 2.0 Beta 2 and Sync Gateway 2.0 Beta 2. NOTE that
Couchbase Lite 2.0 Beta 2 clients require Sync Gateway 2.0 Beta 2. Please
refer to the [Compatibility matrix ]
<https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=swift#compatibility-matrix> for
details.
You can download the latest Beta Build from our Downloads page under
âPre-Releaseâ versions : https://www.couchbase.com/downloads
The second beta release includes following major changes -
- Updates to behavior of SaveDocument API and automatic conflict
resolution policy. (Related [blog
<https://blog.couchbase.com/document-conflicts-couchbase-mobile/>] ).
- Encryption is moved out of 2.0 release
- Replication bug fixes and optimizations
- General performance improvements
We have two versions of the build now - Community Edition (CE) and an
Enterprise Edition (EE). Both editions are free to use for development
purposes. Enterprise edition has some stipulations when you go production.
- This is the [CE License]
<https://github.com/couchbase/couchbase-lite-net/blob/master/LICENSE>
- This is the [EE License]
The Couchbase Lite 2.0 Beta release is available for iOS(Swift, ObjC),
.NET (UWP, Xamarin) and Android platforms . Xamarin will a CE only release
in 2.0.
***Links to platform specific release notes -***
- [Sync Gateway 2.0]
<https://developer.couchbase.com/documentation/mobile/2.0/references/sync-gateway/release-notes/index.html>
- [Swift/ObjC]
<https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=swift>
- [.Net]
- [Android]
<https://developer.couchbase.com/documentation/mobile/2.0/references/couchbase-lite/release-notes/index.html?language=java>
***Related Blogs :***
- [Introducing Queries in Couchbase Lite 2.0]
<https://blog.couchbase.com/sql-for-json-query-interface-couchbase-mobile/>
- [Introducing Full Text Search in Couchbase Lite 2.0]
<https://blog.couchbase.com/full-text-search-couchbase-mobile-2-0/>
- [Querying Array Collections in Lite]
<https://blog.couchbase.com/querying-array-collections-couchbase-mobile/>
- [Replication in Couchbase Mobile 2.0]
<https://blog.couchbase.com/data-replication-couchbase-mobile/>
- [Automatic Conflict Resolution in Couchbase Mobile 2.0]
<https://blog.couchbase.com/document-conflicts-couchbase-mobile/>
- [Join Queries in Couchbase Lite 2.0
<https://blog.couchbase.com/join-queries-couchbase-mobile/>]
- [Certificate Pinning in Android with Couchbase Mobile 2.0]
<https://blog.couchbase.com/certificate-pinning-android-with-couchbase-mobile/>
***Sample Apps :***
https://github.com/couchbaselabs/mobile-training-todo/tree/feature/2.0
https://github.com/couchbaselabs/mobile-travel-sample
***About Couchbase Mobile 2.0:***
Couchbase Mobile 2.0 is a groundbreaking new release for Couchbase
Mobile. Key enhancements include a cross-platform common core, new and
improved Query API with Full-Text search capabilities, automatic conflict
resolution and a new web sockets based replication protocol
***About Beta Builds:***
Beta release is a way for you to test the latest functionality of a
release before it is generally available. These will eventually become
production releases with full support when they are stable and features are
complete.

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/3eb0c1c0-cec0-4a82-92df-fb832895474d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Traun Leyden

2018-03-21 17:55:18 UTC

Permalink

Hey Ben,

You are correct in your assumptions that all conflict resolution in 2.0
will be wallclock-based "last write wins", since there is no longer an API
to plugin custom conflict resolvers. (previous 2.0 beta versions did have
this feature)

I can give you some insight into the thinking of the product management at
Couchbase on this issue. Basically there appears to be a very small
minority of users that will actually need to implement custom conflict
resolvers based on their use case, and including this into the API raises
the complexity quite a bit. So the thinking was to rip this out in 2.0,
but if enough users complain, re-add it in 2.1.

I'm not in product management at Couchbase, but I'll make sure they see
your feedback. If you have a channel with Couchbase sales or support, I'd
definitely use that channel as well to try to influence the product
direction.

Also, if you are able to post details on your particular use case that
highlights the need for custom conflict resolvers, that will help make a
case for re-adding it.

Thanks again for posting!

Post by Ben Kennedy
I am extremely concerned about the changes to conflict resolution in 2.0,
as elucidated in the linked blog post.
In short, my understanding is that there is no longer any way for the
client to deal with conflicts arising from a pull replication (where a new
local revision conflicts with one delivered by Sync Gateway). This seems
like it will promise ongoing non-deterministic and silent data loss when
operating offline (or, indeed, when racing against other mobile clients
speaking to Sync Gateway). Really?
This issue is serious enough I wanted to raise it for clarification here
(despite having also posted a reply on the blog post).
-ben

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/f4a0423e-9051-4ae8-ab7a-9ef1e1483d1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ben Kennedy

2018-03-21 19:02:06 UTC

Permalink

You are correct in your assumptions that all conflict resolution in 2.0 will be wallclock-based "last write wins", since there is no longer an API to plugin custom conflict resolvers. (previous 2.0 beta versions did have this feature)

What prompted its removal?

Basically there appears to be a very small minority of users that will actually need to implement custom conflict resolvers based on their use case, and including this into the API raises the complexity quite a bit.

What sort of complexity?

We're still building with DB021 at the moment (due to the need to target Sync Gateway 1.5 since we're not yet in a position to deploy SG beta to our server environment), but there it's been possible to register a conflict resolver with the replicator. I presume that if/when a conflicting rev comes down in a pull, the resolver would be called, and I could return an appropriate rev (be it A, B, or a new merged C).

Granted, our development on this app is still in early enough stages that we haven't gotten to the point of implementing or exercising conflict resolution logic yet, but the principle seemed straightforward. I wonder what I'm missing.

Also, if you are able to post details on your particular use case that highlights the need for custom conflict resolvers, that will help make a case for re-adding it.

Priya wrote me directly asking for a similar case, so I'll reiterate here the explanation I gave her, for the benefit of you and others:

Our application (iOS, Android, and web) services financial accounting for small-business customers. The main area under development is mobile capture and classification of financial documents (e.g. expense receipts, tax forms) both in the field and at a computer.

Typically, one or more users might be making different edits to a particular document at any given time. For example, a person might purchase some supplies at a shop and file the expense immediately from her phone. An hour later while at a coffee shop she might supplement the record with some more details (e.g. notes on items purchased). Meanwhile, in the interim or afterwards, a data-entry clerk might transcribe some fields from the attached image into well-formed data fields (e.g. price, date, invoice number). An accountant back at the office might start to act on the expense and enter it into the general ledger. A project manager might also concurrently assign some of the bought items to a project.

All of these actions would involve making changes (additions, edits, deletions) to a variety of fields in a particular Couchbase document that embodies the purchase.

In several of our document types, for auditing purposes, changes and additions made by various users are added to an "annotations" array. At any given time the app's business logic examines the array in order to create a current picture of the represented data. This array is expected to be appended to at random.

As you should now intuit, it is crucial that additions to the "annotations" array be coalesced from sibling revisions in the face of a conflict, rather than one particular set chosen at random.

Couchbase Lite is extremely well-suited to our application both for its use of non-structured documents and its offline performance. However, a lack of control over conflict resolution makes offline use dangerous and unreliable; even online use would become unpredictable if more than a single client expects to manipulate the same document (via SG).

cheers,

-ben

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/339CD153-1D3A-40A1-B19C-BD59837FCFEA%40kashoo.com.
For more options, visit https://groups.google.com/d/optout.

Traun Leyden

2018-03-21 23:39:59 UTC

Permalink

Post by Traun Leyden

Post by Traun Leyden
You are correct in your assumptions that all conflict resolution in 2.0

will be wallclock-based "last write wins", since there is no longer an API
to plugin custom conflict resolvers. (previous 2.0 beta versions did have
this feature)
What prompted its removal?

Sorry but I don't know the exact reason. It may have been related to
assessing the testing/documentation effort.

Post by Traun Leyden

Post by Traun Leyden
Basically there appears to be a very small minority of users that will

actually need to implement custom conflict resolvers based on their use
case, and including this into the API raises the complexity quite a bit.
What sort of complexity?

Maybe "surface area" is a better way to put it. Any feature has to be
thoroughly tested and documented. Rather than delay the release, sometimes
features need to be removed and postponed until (potential) future releases.

Post by Traun Leyden
We're still building with DB021 at the moment (due to the need to target
Sync Gateway 1.5 since we're not yet in a position to deploy SG beta to our
server environment), but there it's been possible to register a conflict
resolver with the replicator. I presume that if/when a conflicting rev
comes down in a pull, the resolver would be called, and I could return an
appropriate rev (be it A, B, or a new merged C).
Granted, our development on this app is still in early enough stages that
we haven't gotten to the point of implementing or exercising conflict
resolution logic yet, but the principle seemed straightforward. I wonder
what I'm missing.

I don't think you're missing anything, and yes the principle is
straightforward.

Post by Traun Leyden

Post by Traun Leyden
Also, if you are able to post details on your particular use case that

highlights the need for custom conflict resolvers, that will help make a
case for re-adding it.
Priya wrote me directly asking for a similar case, so I'll reiterate here
Our application (iOS, Android, and web) services financial accounting for
small-business customers. The main area under development is mobile capture
and classification of financial documents (e.g. expense receipts, tax
forms) both in the field and at a computer.
Typically, one or more users might be making different edits to a
particular document at any given time. For example, a person might purchase
some supplies at a shop and file the expense immediately from her phone. An
hour later while at a coffee shop she might supplement the record with some
more details (e.g. notes on items purchased). Meanwhile, in the interim or
afterwards, a data-entry clerk might transcribe some fields from the
attached image into well-formed data fields (e.g. price, date, invoice
number). An accountant back at the office might start to act on the expense
and enter it into the general ledger. A project manager might also
concurrently assign some of the bought items to a project.
All of these actions would involve making changes (additions, edits,
deletions) to a variety of fields in a particular Couchbase document that
embodies the purchase.
In several of our document types, for auditing purposes, changes and
additions made by various users are added to an "annotations" array. At any
given time the app's business logic examines the array in order to create a
current picture of the represented data. This array is expected to be
appended to at random.
As you should now intuit, it is crucial that additions to the
"annotations" array be coalesced from sibling revisions in the face of a
conflict, rather than one particular set chosen at random.
Couchbase Lite is extremely well-suited to our application both for its
use of non-structured documents and its offline performance. However, a
lack of control over conflict resolution makes offline use dangerous and
unreliable; even online use would become unpredictable if more than a
single client expects to manipulate the same document (via SG).

Ok thanks. If you have a hard requirement to keep the annotations together
in a single document, this seems like a perfectly reasonable case where
you'd need to merge the annotations w/ some custom business logic.

Post by Traun Leyden
cheers,
-ben

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/CACSSHCGPnFsatWwwf3SZovxLzGtkCKQwQvPr_3Ok3osokJjMVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Ben Kennedy

2018-04-12 19:28:40 UTC

Permalink

Congratulations to the CBL team on the GA release of 2.0!

Unless I have missed it, nothing further has been said on the subject of
this replication design flaw. Given Couchbase [Lite]'s reputation for data
integrity, and considering the expectations of those planning to migrate
from 1.x, I am surprised that there isn't any allusion or mention of this
in the release notes or getting-started docs. (The latter even includes a
list of âbugsâ and âknown issuesâ at the bottom; wouldn't this type of
thing warrant an entry?)

-b

Post by Traun Leyden

Post by Traun Leyden
You are correct in your assumptions that all conflict resolution in 2.0

will be wallclock-based "last write wins", since there is no longer an API
to plugin custom conflict resolvers. (previous 2.0 beta versions did have
this feature)
What prompted its removal?

Sorry but I don't know the exact reason. It may have been related to
assessing the testing/documentation effort.

Post by Traun Leyden

Post by Traun Leyden
Basically there appears to be a very small minority of users that will

actually need to implement custom conflict resolvers based on their use
case, and including this into the API raises the complexity quite a bit.
What sort of complexity?

I don't think you're missing anything, and yes the principle is
straightforward.

Post by Traun Leyden

Post by Traun Leyden
Also, if you are able to post details on your particular use case that

Post by Traun Leyden
cheers,
-ben

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/38fb2cb8-0558-4747-9a2c-a9dc7fb30a00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Priya Rajagopal

2018-04-12 21:23:00 UTC

Permalink

Hi Ben
The automatic conflict resolution process in 2.0 was designed as such based
on feedback we received from a number of our customers on 1.x. Hence, it is
not listed as a bug or as a known issue because it is "working as designed"
!

That said, we understand that the automatic conflict resolution may not be
applicable in some instances. To that end, we are are consolidating
use-case feedback from users such as yourself to determine the optimal way
to design the system. So this would be a future enhancement - it wouldnât
make the 2.1 release (in couple months) but stay tuned .

Again, appreciate your feedback and details on your use case.

-Priya

Post by Ben Kennedy
Congratulations to the CBL team on the GA release of 2.0!
Unless I have missed it, nothing further has been said on the subject of
this replication design flaw. Given Couchbase [Lite]'s reputation for data
integrity, and considering the expectations of those planning to migrate
from 1.x, I am surprised that there isn't any allusion or mention of this
in the release notes or getting-started docs. (The latter even includes a
list of âbugsâ and âknown issuesâ at the bottom; wouldn't this type of
thing warrant an entry?)
-b

Post by Traun Leyden

Post by Traun Leyden
You are correct in your assumptions that all conflict resolution in

2.0 will be wallclock-based "last write wins", since there is no longer an
API to plugin custom conflict resolvers. (previous 2.0 beta versions did
have this feature)
What prompted its removal?

Sorry but I don't know the exact reason. It may have been related to
assessing the testing/documentation effort.

Post by Traun Leyden
Basically there appears to be a very small minority of users that will

actually need to implement custom conflict resolvers based on their use
case, and including this into the API raises the complexity quite a bit.
What sort of complexity?

We're still building with DB021 at the moment (due to the need to target
Sync Gateway 1.5 since we're not yet in a position to deploy SG beta to our
server environment), but there it's been possible to register a conflict
resolver with the replicator. I presume that if/when a conflicting rev
comes down in a pull, the resolver would be called, and I could return an
appropriate rev (be it A, B, or a new merged C).
Granted, our development on this app is still in early enough stages
that we haven't gotten to the point of implementing or exercising conflict
resolution logic yet, but the principle seemed straightforward. I wonder
what I'm missing.

I don't think you're missing anything, and yes the principle is
straightforward.

Post by Traun Leyden
Also, if you are able to post details on your particular use case that

highlights the need for custom conflict resolvers, that will help make a
case for re-adding it.
Priya wrote me directly asking for a similar case, so I'll reiterate
Our application (iOS, Android, and web) services financial accounting
for small-business customers. The main area under development is mobile
capture and classification of financial documents (e.g. expense receipts,
tax forms) both in the field and at a computer.
Typically, one or more users might be making different edits to a
particular document at any given time. For example, a person might purchase
some supplies at a shop and file the expense immediately from her phone. An
hour later while at a coffee shop she might supplement the record with some
more details (e.g. notes on items purchased). Meanwhile, in the interim or
afterwards, a data-entry clerk might transcribe some fields from the
attached image into well-formed data fields (e.g. price, date, invoice
number). An accountant back at the office might start to act on the expense
and enter it into the general ledger. A project manager might also
concurrently assign some of the bought items to a project.
All of these actions would involve making changes (additions, edits,
deletions) to a variety of fields in a particular Couchbase document that
embodies the purchase.
In several of our document types, for auditing purposes, changes and
additions made by various users are added to an "annotations" array. At any
given time the app's business logic examines the array in order to create a
current picture of the represented data. This array is expected to be
appended to at random.
As you should now intuit, it is crucial that additions to the
"annotations" array be coalesced from sibling revisions in the face of a
conflict, rather than one particular set chosen at random.
Couchbase Lite is extremely well-suited to our application both for its
use of non-structured documents and its offline performance. However, a
lack of control over conflict resolution makes offline use dangerous and
unreliable; even online use would become unpredictable if more than a
single client expects to manipulate the same document (via SG).

Ok thanks. If you have a hard requirement to keep the annotations
together in a single document, this seems like a perfectly reasonable case
where you'd need to merge the annotations w/ some custom business logic.

cheers,
-ben

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+***@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/e5ef3755-5d5f-42d3-bc59-0e2cc3ddc4c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.