Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: A question about attachments, stubs, and revpos
From: Damien Katz <damien@apache.org>
In-Reply-To: <AANLkTikgA_T7Mbi2shUu63QokqKTT3PjRaTIDoHyskl2@mail.gmail.com>
Date: Wed, 23 Jun 2010 10:29:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F4EEA33-2F69-447F-8B7C-EDCEB8EA643E@apache.org>
References: <AANLkTikgA_T7Mbi2shUu63QokqKTT3PjRaTIDoHyskl2@mail.gmail.com>
To: user@couchdb.apache.org


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.
>=20
> I've begun to implement attachments, and I'm a bit stuck about how to =
go
> forward.
>=20
> Basically, I want to know how I can:
>=20
> 1) GET a document and store it in an object
> 2) PUT an attachment to that document
> 3) PUT that document with revised fields
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> I can see two options to handle this:
>=20
> 1) fetch the document again and grab the _attachments and find the new
> attachment and merge it in with the local document
>=20
> 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.

-Damien

>=20
> * 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
>=20
> My question is, what would an experienced CouchDB developer do in this
> situation?
>=20
>=20
> --=20
> Caleb Land