Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com
 designates 209.85.214.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=BW7QAdmdWB+dS0rwISvjIMIHtcQnaqGNkenI3EH8U6mFPk63WzqsLW4aj4f1c1VcJO
         3NYW2GJf6gw1Qvtvmau3+p4wxbsAgqbpCogcrv/Jpf+0x41ITvRSG8wNp/qPAJeOaUW9
         hA5ZtZ5WZ4GIdcKwYzgJ7fS1sp96KIngj05PQ=
MIME-Version: 1.0
In-Reply-To: <vbxf2lwyr9i0g3jjk2krhoox.1297176867019@email.android.com>
References: <vbxf2lwyr9i0g3jjk2krhoox.1297176867019@email.android.com>
Date: Tue, 8 Feb 2011 15:56:01 +0000
Message-ID: <AANLkTik1MFs7Q3psyFt9QDKq9ybGQjeBLXJ9vmyqb8jg@mail.gmail.com>
Subject: Re: Atomic update of multiple attachments?
From: Robert Newson <robert.newson@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Again, there's an atomic method for uploading documents and
attachments using a multipart/related PUT call.

The COPY suggestion was for if you wanted to build the new doc in
stages somewhere else, the final (atomic) step would be to copy that
one over to the new one (and then you clean up the temp one).

B.

On Tue, Feb 8, 2011 at 3:48 PM, Robert Johnson <robert@rowanshire.net> wrot=
e:
> I don't think copy does it because you end up with 2 identical documents =
including the attachments, so you would need to copy the document and then =
immediately update the new document by removing the attachments and decreme=
nting the counter for attached documents. As couch will not guarantee that =
both the copy and update will complete you could end up with a duplicate do=
cument in your database. You have a similar problem with the temp document =
idea, and in either case require an identifier that is unique to a document=
 and a version number within the document (other than the couch generated o=
nes) so you can delete the old version with certainty that you are deleting=
 the right one.
>
> The chances of a failed update and hence a duplicate document are low if =
you code carefully but they exist and you may or may not be happy to take t=
he risk - much will depend on the impact of the existence of a duplicate.
>
> The best secure way I can come up with relies on unique attachment names =
and works as =A0follows:-
>
> Proceed as per my original suggestion for adding new documents but in add=
ition have an additional attribute which is in fact an array of attributes =
per pseudo code below
>
> Attached_docs[]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Eventual_count
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0Current_count
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Docs []
>
> When you first load a new document the array will have one element and th=
e eventual and current counts will be the same as the original count attrib=
utes I suggested and the docs array will have a list of the attached docume=
nts that has the same names in it as the system generated _attachements str=
ucture.
>
> Now for update, add a new element to the end of the attached_docs array w=
ith the expected count set to the new number of attachements expected and t=
he actual count set to zero and the docs array empty. Do not alter the valu=
es in eventual_attachement_count or attachement_count_so_far. Load up your =
new set of attachements updating only the counts in the new array element a=
nd put the new document names in the docs array as you load them.
>
> In your display code, you would need to look at the last element in the a=
ttached_docs array and if the eventual and actual counts values are the sam=
e then the docs array in that element contains the names of the attachments=
 to show. If the values are different go to the previous element of the att=
ached_docs array until you find an element that qualifies.
>
> This mechanism is I believe rock solid as
>
> The document will not show up in the view until there is one full set of =
attachements loaded, while loading a new set the old set will still be visi=
ble and you can identify which set to show easily, once the new set is full=
y loaded it becomes immediately visible and there is no possibility of gett=
ing a duplicate document. The only requirement is that you have to ensure y=
our attachement names are unique within a document but these are in your di=
rect control. With some careful coding and paranoid checking you are even s=
ecure against a failed attachement upload.
>
> Thats the best I can come up with.
>
> Bob
>
> Robert Newson <robert.newson@gmail.com> wrote:
>
>>You could also use the COPY feature. :)
>>
>>On Mon, Feb 7, 2011 at 11:59 PM, Wayne Conrad <wayne@databill.com> wrote:
>>> Bob, One of my needs is that requestors can get the most recent "comple=
te"
>>> set of attachments, even while a new set is being assembled. =A0I've no=
 sense
>>> of what it takes to work with previous version of a document, esp. sinc=
e (as
>>> I understand it) replication doesn't transfer old revisions of document=
s.
>>> =A0Do you think your idea can be made to work with this need?
>>>
>>> I'm wondering if something can be done that's similar to how we
>>> create/rename files in Unix. =A0Can I create a temporary document, load=
 it up
>>> with attachments, and then rename it?
>>>
>>> Wayne
>>>
>>> On 02/07/11 16:38, Robert Johnson wrote:
>>>>
>>>> Create your document with attributes "eventual_attachment _count" (set
>>>> this to the expected count) and "attachment_count_so_far" (set this to
>>>> zero).
>>>> As you add each attachment, increment "attachment_count_so_far"
>>>>
>>>> Create a view which only emits when "attachment_count_so_far" =3D
>>>> "eventual_attachment _count"
>>>>
>>>>
>>>> For update:-
>>>>
>>>> Remove docs and decrement "attachment_count_so_far"
>>>> Reset "eventual_attachment _count"if necessary
>>>> Add new attachments and increment "attachment_count_so_far"
>>>>
>>>> Does this work for you?
>>>>
>>>> Bob
>>>>
>>>> On 7 Feb 2011, at 23:25, Wayne Conrad wrote:
>>>>
>>>>> Is there anything I can do to achieve the illusion of atomic update o=
f a
>>>>> set of attachments? =A0Here's the effect I'd like:
>>>>>
>>>>> For create:
>>>>> 1. Create a document.
>>>>> 2. Add attachments to it.
>>>>> 3. Only now does the document and all of its attachments become visib=
le.
>>>>>
>>>>> For update:
>>>>> 1. Delete all of the document's attachments.
>>>>> 2. Add a new set of attachments to the document.
>>>>> 3. Only now does the new set of attachments appear to replace the old=
.
>>>>>
>>>>> I'm using Couchdb 1.0.2 and CouchRest 1.0.1. =A0I'm not opposed to ch=
eating
>>>>> to achieve my goal. =A0Suggestions of "Did you think of doing this-ot=
her-thing
>>>>> instead?" are also welcome.
>>>>
>>>
>>>
>