Thanks Jens,

I am using the bulk api as described in Posting Existing Revisions[1] already, 
and I pass the the new and the past rev ids in _revisions.ids. But still I do 
get errors.

But I think I've spotted an issue, I'll check that one first. Cheers!


[1] 
http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API#Transactional_Semantics_with_Bulk_Updates
  

--  
Gregor Martynus


On Friday, 24. May 2013 at 02:13, Jens Alfke wrote:

>  
> On May 23, 2013, at 1:28 PM, Gregor Martynus <[email protected] 
> (mailto:[email protected])> wrote:
>  
> > I'm using the edits=false flag to push changes from the browser to the 
> > couch, to prevent that data can get lost.
>  
> Are you _sure_ you want to do that? It can create conflicts. Regular PUTs 
> won’t lose data; the 409 Conflict error is to alert the client that there’s a 
> newer revision on the server, so the client can do the necessary conflict 
> resolution and then retry. It’s generally better to handle conflicts before 
> they’re saved, rather than afterwards, because you’re more flexible in how to 
> interact with the user.
>  
> > My current implementations randomly generates a _rev number and adds the 
> > _revisions attribute with the current _rev and the newly generated _rev 
> > number. But that leads to conflicts. I was told that the _rev number has to 
> > be calculated based on the objects.
>  
> Don’t make up your own revIDs! If you really, really want to create conflicts 
> on the server, use the all_or_nothing mode of _bulk_docs instead:
> http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API#Transactional_Semantics_with_Bulk_Updates
>  
> —Jens  

Reply via email to