Side-note: You do know it's ?new_edits=false, not edits=false, right? B.
On 24 May 2013 12:04, Gregor Martynus <[email protected]> wrote: > Thanks Jason, I've a better understanding of the ?edits=false flag now and > also what the cause of my problem is. After looking more into it, I've found > that conflicts are not created on every POST /_bulk_docs?edits=false, but > only for some documents. And the reason is that the `_revisions.ids` history > is not correct in all cases, so it must be a Hoodie bug. > > PS: Special thanks that you found the time to respond in these exciting times > :-) Very happy for you & IrisCouch > > -- > Gregor Martynus > > > On Friday, 24. May 2013 at 07:36, Jason Smith wrote: > >> Calculating _rev "correctly" depends on what you need. >> >> If you and I have the same document and make the same changes except _rev >> (and _revisions), then we will get a conflict when we replicate to each >> other. >> >> The only project I know that uses edits=false somewhat successfully is >> mikeal/replicate. It might help, although it gets its _revisions value from >> CouchDB, it doesn't calculate anything. >> >> Can you paste some example documents (with the _revisions) value? >> >> >> On Fri, May 24, 2013 at 3:28 AM, Gregor Martynus <[email protected] >> (mailto:[email protected])>wrote: >> >> > Hey, >> > >> > I'm using the edits=false flag to push changes from the browser to the >> > couch, to prevent that data can get lost. 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. >> > >> > I try to find out how to calculate a new the _rev number correctly but >> > can't figure it out. I've described the issues here: >> > https://github.com/hoodiehq/hoodie.js/issues/66 >> > >> > Would really appreciate your help >> > >> > -- >> > Gregor >> > >> >> >> > >
