I posted the issue: https://issues.apache.org/jira/browse/COUCHDB-809
and I made a small patch that fixes the issue (though I'm very green at Erlang, so this might not be sufficient): http://github.com/caleb/couchdb/commit/90fd0c411b682d5bfcc05c9055a95d4cc7e08895 What do you think? On Wed, Jun 23, 2010 at 1:59 PM, Damien Katz <[email protected]> wrote: > > On Jun 23, 2010, at 10:39 AM, Caleb Land wrote: > > > On Wed, Jun 23, 2010 at 1:29 PM, Damien Katz <[email protected]> wrote: > > > >> > >> On Jun 23, 2010, at 10:24 AM, Caleb Land wrote: > >> > >>> I'm writing a CouchDB library for ruby (who isn't these days :)), > partly > >> for > >>> my own use, and partly to teach myself about how couch works, and play > >> with > >>> some ideas I have about working with it. > >>> > >>> I've begun to implement attachments, and I'm a bit stuck about how to > go > >>> forward. > >>> > >>> Basically, I want to know how I can: > >>> > >>> 1) GET a document and store it in an object > >>> 2) PUT an attachment to that document > >>> 3) PUT that document with revised fields > >>> > >>> The problem is, when I PUT the attachment, the document is updated and > >> the > >>> new document rev is returned. I can easily stuff this rev into the _rev > >>> field of my local document (like everyone does when they PUT a > >> document... > >>> so subsequent PUTs use the correct _rev), but the problem comes when I > >> need > >>> to PUT the document, and that document doesn't have the stub for the > >> newly > >>> uploaded attachment. > >>> > >>> I asked this question on IRC and got a reasonable answer back: Don't > >> modify > >>> a document twice in a row without fetching it in between. > >>> > >>> This makes sense, but then I thought about how when we save documents, > we > >>> update our local copy's _rev with the rev returned by the server so we > >>> wouldn't have to fetch it again. > >>> > >>> Also, if the local document has some other fields that have changed > >> (let's > >>> say so that we could do validation before uploading the attachments), > >> then > >>> we have problems. > >>> > >>> I can see two options to handle this: > >>> > >>> 1) fetch the document again and grab the _attachments and find the new > >>> attachment and merge it in with the local document > >>> > >>> 2) build a stub and inject it into the local document: > >>> { > >>> 'stub': true, > >>> 'revpos': parseInt(return_from_attachment_put['rev']) // * > >>> } > >> > >> I'd use the second option, though I'm pretty sure you don't need the > revpos > >> for a stub, so just leave that out and it should be fine. > >> > >> > > That's what I thought too, but if I don't include the revpos, I get an > > precondition failed status, with the error: > > > > {"error":"missing_stub","reason":"id:test, name:graph.html"} > > > > should I raise an issue in JIRA? > > Yes, please do. > > -Damien > > > > > > >> -Damien > >> > >>> > >>> * I'm not sure about this, since I didn't see a formal definition for > >>> 'revpos' anywhere, but this seems to be how it works > >>> > >>> My question is, what would an experienced CouchDB developer do in this > >>> situation? > >>> > >>> > >>> -- > >>> Caleb Land > >> > >> > > > > > > -- > > Caleb Land > > -- Caleb Land
