You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Peter Norwich <ri...@yahoo.co.uk> on 2015/05/14 15:38:28 UTC
How to 'force write' in v2.0 ?
Is bulk_docs' all_or_nothing going to be supported in 2.0 ?
I see dev preview says "not supported yet".
If not, what will be the new way of introducing conflict in 2.0 ? Is there a 'force write' flag during PUT ?
I just need a way to always write successfully.
My use case:
- offline client, will upload the doc when online
- server saves doc, return winning rev and conflict info to client
- client can fetch all conflicts and manually resolve them
Thanks :)
Peter
Re: How to 'force write' in v2.0 ?
Posted by Robert Samuel Newson <rn...@apache.org>.
"all_or_nothing":true continues to work in couchdb 2.0.
The semantic for all_or_nothing: true changed just before couchdb 1.0 came out to allow it to work in a (future) cluster. Instead of a true all-or-nothing, what happens instead is that conflicts are introduced if necessary.
A side-effect of a couchdb database being a single file meant that a bulk_docs write would also be atomic, this does not hold in 2.0 (though it holds at the shard level, which is no help to you at all).
Personally, I think we should remove the option entirely, it doesn’t really do what the name implies, and it cannot be made to do so, but it works about the same in 2.0 as it did in 1.0, for what that’s worth.
B.
> On 15 May 2015, at 11:05, Dale Harvey <da...@arandomurl.com> wrote:
>
> Those steps look remarkably similiar to how the replicator works, wondering why you arent using that?
>
> user@couchdb.apache.org wrote:
>> Thanks for your suggestion,
>>
>> I'll just write my steps here to benefit other users that wants all_or_nothing in v2.0:
>> 1. For each docs:
>> - retrieve _revisions using GET /db/doc?rev=latest_rev&revs=true
>> - generate new revision ID (I use HMAC here), prepend it to _revisions.ids
>> - increase _revisions.start
>> 2. POST bulk_docs with new_edits:false
>>
>> It works, but feels very hackish as there are now n requests (one for each doc) to get
>> _revisions instead of only one all_or_nothing.
>>
>> I assume the difficulty of all_or_nothing in v2.0 comes multi-master and having
>> to rollback multiple docs on validation failure.
>>
>> So I suggest something simpler like: PUT /db/doc?rev=latest_rev&force=true
>> that always return success. Developers can then loop on each document to mimic
>> previous bulk_docs semantic.
>> Seems possible to me, but I don't understand CouchDB internals.
>>
>> Thanks for your help :)
>>
>> --------------------------------------------
>> On Fri, 15/5/15, Alexander Shorin <kx...@gmail.com> wrote:
>>
>> Subject: Re: How to 'force write' in v2.0 ?
>> To: rimaha2000-couch@yahoo.co.uk
>> Cc: "user@couchdb.apache.org" <us...@couchdb.apache.org>
>> Date: Friday, 15 May, 2015, 2:51
>>
>> On Thu, May 14, 2015 at
>> 10:22 PM, Peter Norwich
>> <ri...@yahoo.co.uk>
>> wrote:
>>>>> So your case if about
>> just blindly push bulk docs from time to time and not care
>> about any conflicts they may produce?
>>>
>>> No. My case in
>> detail:
>>> - client modify doc during
>> offline
>>> - when online, client sync with
>> server (this used to be _bulk_docs all_or_nothing)
>>> write should always be
>> succesful, so that offline change won't be lost
>>> - server returns winning rev along with
>> all possible conflicts
>>> - client resolve
>> conflicts manually
>>> - client save the
>> latest _rev for next sync.
>>>
>>> tldr: write always success, read returns
>> all conflicts.
>>> See this proposal
>> written 3 years ago https://gist.github.com/rnewson/2387973
>>> Point number 1 is exactly what I need.
>>
>> all_or_nothing couldn't be
>> implemented as we can promise no more
>> semantic that lies behind it.
>>
>> So what could you do:
>> - use _bulk_docs with new_edits: false
>> introducing conflicts. For the
>> new docs
>> required _rev replace with dummy uuid;
>> -
>> wait for merge or apply manually
>> https://github.com/apache/couchdb-chttpd/pull/33
>> patch in order to
>> fetch all conflicts in
>> bulk (as you know all your docs ids);
>> -
>> proceed with your old logic as you have now all the revs and
>> all the
>> conflicts.
>>
>> Not sure if Point number 1 from referenced
>> approach will be in 2.0,
>> but so far it is
>> not.
>>
>> --
>> ,,,^..^,,,
>>
>
> --
> Sent Using Firefox OS
Re: How to 'force write' in v2.0 ?
Posted by Alexander Shorin <kx...@gmail.com>.
On Sat, May 16, 2015 at 5:21 AM, Peter Norwich
<ri...@yahoo.co.uk> wrote:
> Using replicator means client has to implement replication protocol.
Replication protocol is not a magic, but a usage of CouchDB API in
special order to send only missing docs/revisions from source to
target in the end.
It's pretty good described in the docs:
http://docs.couchdb.org/en/latest/replication/protocol.html
In fact, it would be the same as want you already doing, but you'll
add few more requests (see API reference in the end) which will help
you avoid unnecessary conflicts creation and help to make your sync
incremental.
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Peter Norwich <ri...@yahoo.co.uk>.
Using replicator means client has to implement replication protocol.
I didn't want to do that, what I need is just a 'force write'. That I ended
up implementing something similar to replication is because that's the
only way to introduce conflicts in v2.0
I've ventured with other solutions:
- include CouchDB in distributable (using rcouch) -> size too big
- PouchDB -> mine is a non-browser app.
--------------------------------------------
On Fri, 15/5/15, Dale Harvey <da...@arandomurl.com> wrote:
Subject: Re: How to 'force write' in v2.0 ?
To: "Alexander Shorin" <kx...@gmail.com>
Cc: user@couchdb.apache.org
Date: Friday, 15 May, 2015, 17:05
Those steps look remarkably similiar
to how the replicator works, wondering why you arent using
that?
user@couchdb.apache.org
wrote:
> Thanks for your suggestion,
>
> I'll just write my steps here to benefit other users
that wants all_or_nothing in v2.0:
> 1. For each docs:
> - retrieve _revisions using GET
/db/doc?rev=latest_rev&revs=true
> - generate new revision ID (I use HMAC
here), prepend it to _revisions.ids
> - increase _revisions.start
> 2. POST bulk_docs with new_edits:false
>
> It works, but feels very hackish as there are now n
requests (one for each doc) to get
> _revisions instead of only one all_or_nothing.
>
> I assume the difficulty of all_or_nothing in v2.0 comes
multi-master and having
> to rollback multiple docs on validation failure.
>
> So I suggest something simpler like: PUT
/db/doc?rev=latest_rev&force=true
> that always return success. Developers can then loop on
each document to mimic
> previous bulk_docs semantic.
> Seems possible to me, but I don't understand CouchDB
internals.
>
> Thanks for your help :)
>
> --------------------------------------------
> On Fri, 15/5/15, Alexander Shorin <kx...@gmail.com>
wrote:
>
> Subject: Re: How to 'force write' in v2.0 ?
> To: rimaha2000-couch@yahoo.co.uk
> Cc: "user@couchdb.apache.org"
<us...@couchdb.apache.org>
> Date: Friday, 15 May, 2015, 2:51
>
> On Thu, May 14, 2015 at
> 10:22 PM, Peter Norwich
> <ri...@yahoo.co.uk>
> wrote:
> >>> So your case if about
> just blindly push bulk docs from time to time and
not care
> about any conflicts they may produce?
> >
> > No. My case in
> detail:
> > - client modify doc during
> offline
> > - when online, client sync with
> server (this used to be _bulk_docs
all_or_nothing)
> > write should always be
> succesful, so that offline change won't be lost
> > - server returns winning rev along with
> all possible conflicts
> > - client resolve
> conflicts manually
> > - client save the
> latest _rev for next sync.
> >
> > tldr: write always success, read returns
> all conflicts.
> > See this proposal
> written 3 years ago https://gist.github.com/rnewson/2387973
> > Point number 1 is exactly what I need.
>
> all_or_nothing couldn't be
> implemented as we can promise no more
> semantic that lies behind it.
>
> So what could you do:
> - use _bulk_docs with new_edits: false
> introducing conflicts. For the
> new docs
> required _rev replace with dummy uuid;
> -
> wait for merge or apply manually
> https://github.com/apache/couchdb-chttpd/pull/33
> patch in order to
> fetch all conflicts in
> bulk (as you know all your docs ids);
> -
> proceed with your old logic as you have now all
the revs and
> all the
> conflicts.
>
> Not sure if Point number 1 from referenced
> approach will be in 2.0,
> but so far it is
> not.
>
> --
> ,,,^..^,,,
>
--
Sent Using Firefox OS
Re: How to 'force write' in v2.0 ?
Posted by Dale Harvey <da...@arandomurl.com>.
Those steps look remarkably similiar to how the replicator works, wondering why you arent using that?
user@couchdb.apache.org wrote:
> Thanks for your suggestion,
>
> I'll just write my steps here to benefit other users that wants all_or_nothing in v2.0:
> 1. For each docs:
> - retrieve _revisions using GET /db/doc?rev=latest_rev&revs=true
> - generate new revision ID (I use HMAC here), prepend it to _revisions.ids
> - increase _revisions.start
> 2. POST bulk_docs with new_edits:false
>
> It works, but feels very hackish as there are now n requests (one for each doc) to get
> _revisions instead of only one all_or_nothing.
>
> I assume the difficulty of all_or_nothing in v2.0 comes multi-master and having
> to rollback multiple docs on validation failure.
>
> So I suggest something simpler like: PUT /db/doc?rev=latest_rev&force=true
> that always return success. Developers can then loop on each document to mimic
> previous bulk_docs semantic.
> Seems possible to me, but I don't understand CouchDB internals.
>
> Thanks for your help :)
>
> --------------------------------------------
> On Fri, 15/5/15, Alexander Shorin <kx...@gmail.com> wrote:
>
> Subject: Re: How to 'force write' in v2.0 ?
> To: rimaha2000-couch@yahoo.co.uk
> Cc: "user@couchdb.apache.org" <us...@couchdb.apache.org>
> Date: Friday, 15 May, 2015, 2:51
>
> On Thu, May 14, 2015 at
> 10:22 PM, Peter Norwich
> <ri...@yahoo.co.uk>
> wrote:
> >>> So your case if about
> just blindly push bulk docs from time to time and not care
> about any conflicts they may produce?
> >
> > No. My case in
> detail:
> > - client modify doc during
> offline
> > - when online, client sync with
> server (this used to be _bulk_docs all_or_nothing)
> > write should always be
> succesful, so that offline change won't be lost
> > - server returns winning rev along with
> all possible conflicts
> > - client resolve
> conflicts manually
> > - client save the
> latest _rev for next sync.
> >
> > tldr: write always success, read returns
> all conflicts.
> > See this proposal
> written 3 years ago https://gist.github.com/rnewson/2387973
> > Point number 1 is exactly what I need.
>
> all_or_nothing couldn't be
> implemented as we can promise no more
> semantic that lies behind it.
>
> So what could you do:
> - use _bulk_docs with new_edits: false
> introducing conflicts. For the
> new docs
> required _rev replace with dummy uuid;
> -
> wait for merge or apply manually
> https://github.com/apache/couchdb-chttpd/pull/33
> patch in order to
> fetch all conflicts in
> bulk (as you know all your docs ids);
> -
> proceed with your old logic as you have now all the revs and
> all the
> conflicts.
>
> Not sure if Point number 1 from referenced
> approach will be in 2.0,
> but so far it is
> not.
>
> --
> ,,,^..^,,,
>
--
Sent Using Firefox OS
Re: How to 'force write' in v2.0 ?
Posted by Peter Norwich <ri...@yahoo.co.uk>.
Thanks for your suggestion,
I'll just write my steps here to benefit other users that wants all_or_nothing in v2.0:
1. For each docs:
- retrieve _revisions using GET /db/doc?rev=latest_rev&revs=true
- generate new revision ID (I use HMAC here), prepend it to _revisions.ids
- increase _revisions.start
2. POST bulk_docs with new_edits:false
It works, but feels very hackish as there are now n requests (one for each doc) to get
_revisions instead of only one all_or_nothing.
I assume the difficulty of all_or_nothing in v2.0 comes multi-master and having
to rollback multiple docs on validation failure.
So I suggest something simpler like: PUT /db/doc?rev=latest_rev&force=true
that always return success. Developers can then loop on each document to mimic
previous bulk_docs semantic.
Seems possible to me, but I don't understand CouchDB internals.
Thanks for your help :)
--------------------------------------------
On Fri, 15/5/15, Alexander Shorin <kx...@gmail.com> wrote:
Subject: Re: How to 'force write' in v2.0 ?
To: rimaha2000-couch@yahoo.co.uk
Cc: "user@couchdb.apache.org" <us...@couchdb.apache.org>
Date: Friday, 15 May, 2015, 2:51
On Thu, May 14, 2015 at
10:22 PM, Peter Norwich
<ri...@yahoo.co.uk>
wrote:
>>> So your case if about
just blindly push bulk docs from time to time and not care
about any conflicts they may produce?
>
> No. My case in
detail:
> - client modify doc during
offline
> - when online, client sync with
server (this used to be _bulk_docs all_or_nothing)
> write should always be
succesful, so that offline change won't be lost
> - server returns winning rev along with
all possible conflicts
> - client resolve
conflicts manually
> - client save the
latest _rev for next sync.
>
> tldr: write always success, read returns
all conflicts.
> See this proposal
written 3 years ago https://gist.github.com/rnewson/2387973
> Point number 1 is exactly what I need.
all_or_nothing couldn't be
implemented as we can promise no more
semantic that lies behind it.
So what could you do:
- use _bulk_docs with new_edits: false
introducing conflicts. For the
new docs
required _rev replace with dummy uuid;
-
wait for merge or apply manually
https://github.com/apache/couchdb-chttpd/pull/33
patch in order to
fetch all conflicts in
bulk (as you know all your docs ids);
-
proceed with your old logic as you have now all the revs and
all the
conflicts.
Not sure if Point number 1 from referenced
approach will be in 2.0,
but so far it is
not.
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, May 14, 2015 at 10:22 PM, Peter Norwich
<ri...@yahoo.co.uk> wrote:
>>> So your case if about just blindly push bulk docs from time to time and not care about any conflicts they may produce?
>
> No. My case in detail:
> - client modify doc during offline
> - when online, client sync with server (this used to be _bulk_docs all_or_nothing)
> write should always be succesful, so that offline change won't be lost
> - server returns winning rev along with all possible conflicts
> - client resolve conflicts manually
> - client save the latest _rev for next sync.
>
> tldr: write always success, read returns all conflicts.
> See this proposal written 3 years ago https://gist.github.com/rnewson/2387973
> Point number 1 is exactly what I need.
all_or_nothing couldn't be implemented as we can promise no more
semantic that lies behind it.
So what could you do:
- use _bulk_docs with new_edits: false introducing conflicts. For the
new docs required _rev replace with dummy uuid;
- wait for merge or apply manually
https://github.com/apache/couchdb-chttpd/pull/33 patch in order to
fetch all conflicts in bulk (as you know all your docs ids);
- proceed with your old logic as you have now all the revs and all the
conflicts.
Not sure if Point number 1 from referenced approach will be in 2.0,
but so far it is not.
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Peter Norwich <ri...@yahoo.co.uk>.
>> So your case if about just blindly push bulk docs from time to time and not care about any conflicts they may produce?
No. My case in detail:
- client modify doc during offline
- when online, client sync with server (this used to be _bulk_docs all_or_nothing)
write should always be succesful, so that offline change won't be lost
- server returns winning rev along with all possible conflicts
- client resolve conflicts manually
- client save the latest _rev for next sync.
tldr: write always success, read returns all conflicts.
See this proposal written 3 years ago https://gist.github.com/rnewson/2387973
Point number 1 is exactly what I need.
--------------------------------------------
On Fri, 15/5/15, Alexander Shorin <kx...@gmail.com> wrote:
Subject: Re: How to 'force write' in v2.0 ?
To: rimaha2000-couch@yahoo.co.uk
Cc: "user@couchdb.apache.org" <us...@couchdb.apache.org>
Date: Friday, 15 May, 2015, 0:21
On Thu, May 14, 2015 at
6:58 PM, Peter Norwich
<ri...@yahoo.co.uk>
wrote:
>>> I would recommend you to
use your own field for tracking ancestry and relations and
not generate rev manually
>
> I don't see how it's possible to
do this since new_edits:false expects existing revision
ID.
> and there is no API to just ask
CouchDB to generate rev for a doc.
If you want to update an existed document, than
you should provide any
revision for it.
> I see previous discussion "Making
conflict first class citizens" (http://grokbase.com/t/couchdb/user/124jegc8kn/making-conflicts-first-class-citizens)
> Does anyone know what is the conclusion
?
> It seems to be *exactly* what I need.
But I don't see how to do that now in 2.0.
>
> new_edits:false seems
too convoluted for what seems to be a simple task.
> It's essentially asking developer to
write CouchDB replicator (like PouchDB),
> but my use case is just a lightweight
desktop client (with no knowledge of server DB),
> pushes the doc, and resolve resulting
conflict manually.
So
your case if about just blindly push bulk docs from time to
time
and not care about any conflicts they
may produce?
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, May 14, 2015 at 6:58 PM, Peter Norwich
<ri...@yahoo.co.uk> wrote:
>>> I would recommend you to use your own field for tracking ancestry and relations and not generate rev manually
>
> I don't see how it's possible to do this since new_edits:false expects existing revision ID.
> and there is no API to just ask CouchDB to generate rev for a doc.
If you want to update an existed document, than you should provide any
revision for it.
> I see previous discussion "Making conflict first class citizens" (http://grokbase.com/t/couchdb/user/124jegc8kn/making-conflicts-first-class-citizens)
> Does anyone know what is the conclusion ?
> It seems to be *exactly* what I need. But I don't see how to do that now in 2.0.
>
> new_edits:false seems too convoluted for what seems to be a simple task.
> It's essentially asking developer to write CouchDB replicator (like PouchDB),
> but my use case is just a lightweight desktop client (with no knowledge of server DB),
> pushes the doc, and resolve resulting conflict manually.
So your case if about just blindly push bulk docs from time to time
and not care about any conflicts they may produce?
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Peter Norwich <ri...@yahoo.co.uk>.
>> I would recommend you to use your own field for tracking ancestry and relations and not generate rev manually
I don't see how it's possible to do this since new_edits:false expects existing revision ID.
and there is no API to just ask CouchDB to generate rev for a doc.
I see previous discussion "Making conflict first class citizens" (http://grokbase.com/t/couchdb/user/124jegc8kn/making-conflicts-first-class-citizens)
Does anyone know what is the conclusion ?
It seems to be *exactly* what I need. But I don't see how to do that now in 2.0.
new_edits:false seems too convoluted for what seems to be a simple task.
It's essentially asking developer to write CouchDB replicator (like PouchDB),
but my use case is just a lightweight desktop client (with no knowledge of server DB),
pushes the doc, and resolve resulting conflict manually.
--------------------------------------------
On Thu, 14/5/15, Alexander Shorin <kx...@gmail.com> wrote:
Subject: Re: How to 'force write' in v2.0 ?
To: rimaha2000-couch@yahoo.co.uk
Cc: "user@couchdb.apache.org" <us...@couchdb.apache.org>
Date: Thursday, 14 May, 2015, 22:17
On Thu, May 14, 2015 at
5:40 PM, Peter Norwich
<ri...@yahoo.co.uk>
wrote:
>>> all_or_nothing
doesn't introduces conflicts.
>
> You mean it's the new behavior in 2.0
? in 1.6 all_or_nothing will happily write and introduce
conflicts
> as long as it pass
validation.
>
No, it's not new. new_edits: false is how
replicator sync databases
introducing
conflicts.
But you're
right about all_or_nothing behaviour: sets a
merge_conflicts option which introduces
conflicts as well during rev
tree merge:
https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_db.erl#L757-L790
https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_db_updater.erl#L627-L630
>>> For introducing conflicts, use
new_edits: false
>
> I
tried, but then the client has to generate rev manually and
keep track all parents' revisions all the
> way until revpos 1. Is there simpler
solution ?
> Does the request needs to
list all parents rev or only the latest one ? I tried both
and its successful.
> e.g.:
>
_revisions":{"start":4,"ids":["3595405","877727288","376647","28839289"]}
>
_revisions":{"start":4,"ids":["3595405","877727288"]}
>
> what is the
implication of supplying only the latest rev ?
I would recommend you to use
your own field for tracking ancestry and
relations and not generate rev manually - this
way more opaque for you
and you're not
goes in conflict with CouchDB internals.
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, May 14, 2015 at 5:40 PM, Peter Norwich
<ri...@yahoo.co.uk> wrote:
>>> all_or_nothing doesn't introduces conflicts.
>
> You mean it's the new behavior in 2.0 ? in 1.6 all_or_nothing will happily write and introduce conflicts
> as long as it pass validation.
>
No, it's not new. new_edits: false is how replicator sync databases
introducing conflicts.
But you're right about all_or_nothing behaviour: sets a
merge_conflicts option which introduces conflicts as well during rev
tree merge:
https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_db.erl#L757-L790
https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_db_updater.erl#L627-L630
>>> For introducing conflicts, use new_edits: false
>
> I tried, but then the client has to generate rev manually and keep track all parents' revisions all the
> way until revpos 1. Is there simpler solution ?
> Does the request needs to list all parents rev or only the latest one ? I tried both and its successful.
> e.g.:
> _revisions":{"start":4,"ids":["3595405","877727288","376647","28839289"]}
> _revisions":{"start":4,"ids":["3595405","877727288"]}
>
> what is the implication of supplying only the latest rev ?
I would recommend you to use your own field for tracking ancestry and
relations and not generate rev manually - this way more opaque for you
and you're not goes in conflict with CouchDB internals.
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Peter Norwich <ri...@yahoo.co.uk>.
>> all_or_nothing doesn't introduces conflicts.
You mean it's the new behavior in 2.0 ? in 1.6 all_or_nothing will happily write and introduce conflicts
as long as it pass validation.
>> For introducing conflicts, use new_edits: false
I tried, but then the client has to generate rev manually and keep track all parents' revisions all the
way until revpos 1. Is there simpler solution ?
Does the request needs to list all parents rev or only the latest one ? I tried both and its successful.
e.g.:
_revisions":{"start":4,"ids":["3595405","877727288","376647","28839289"]}
_revisions":{"start":4,"ids":["3595405","877727288"]}
what is the implication of supplying only the latest rev ?
--------------------------------------------
On Thu, 14/5/15, Alexander Shorin <kx...@gmail.com> wrote:
Subject: Re: How to 'force write' in v2.0 ?
To: "user@couchdb.apache.org" <us...@couchdb.apache.org>, rimaha2000-couch@yahoo.co.uk
Date: Thursday, 14 May, 2015, 20:44
all_or_nothing
doesn't introduces conflicts. It allows CouchDB to
return an error response if any write fail.
For introducing conflicts, use new_edits:
false. But this is not a
force write as
validate_doc_update still may block your writes.
--
,,,^..^,,,
Re: How to 'force write' in v2.0 ?
Posted by Alexander Shorin <kx...@gmail.com>.
all_or_nothing doesn't introduces conflicts. It allows CouchDB to
return an error response if any write fail.
For introducing conflicts, use new_edits: false. But this is not a
force write as validate_doc_update still may block your writes.
--
,,,^..^,,,
On Thu, May 14, 2015 at 4:38 PM, Peter Norwich
<ri...@yahoo.co.uk> wrote:
> Is bulk_docs' all_or_nothing going to be supported in 2.0 ?
> I see dev preview says "not supported yet".
>
> If not, what will be the new way of introducing conflict in 2.0 ? Is there a 'force write' flag during PUT ?
> I just need a way to always write successfully.
>
> My use case:
> - offline client, will upload the doc when online
> - server saves doc, return winning rev and conflict info to client
> - client can fetch all conflicts and manually resolve them
>
> Thanks :)
> Peter