couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Caleb Land <caleb.l...@gmail.com>
Subject Re: A question about attachments, stubs, and revpos
Date Thu, 24 Jun 2010 16:05:27 GMT
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 <damien@apache.org> wrote:

>
> 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
>
>


-- 
Caleb Land

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message