On Jun 23, 2010, at 10:39 AM, Caleb Land wrote: > On Wed, Jun 23, 2010 at 1:29 PM, Damien Katz 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