incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: A question about attachments, stubs, and revpos
Date Wed, 23 Jun 2010 17:59:12 GMT

On Jun 23, 2010, at 10:39 AM, Caleb Land wrote:

> On Wed, Jun 23, 2010 at 1:29 PM, Damien Katz <damien@apache.org> 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


Mime
View raw message