Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of alex.barbalex@gmail.com
 designates 209.85.212.52 as permitted sender)
MIME-Version: 1.0
Sender: alex.barbalex@gmail.com
In-Reply-To: 
 <CAEXS1cAXTBKOYArjD4pBRrd9QGRRcU4has9f35Fo_9U-Ur1nhQ@mail.gmail.com>
References: 
 <CA+w3y1gPYHArnt9+PU9ZiBx+oYQgCaHGF0HXAKi60L=34MTySg@mail.gmail.com>
	<CAEXS1cAXTBKOYArjD4pBRrd9QGRRcU4has9f35Fo_9U-Ur1nhQ@mail.gmail.com>
Date: Tue, 23 Aug 2011 01:14:04 +0200
Message-ID: 
 <CA+w3y1gYr5B06WFJm11--2zVi05YeVBW0R=ThdOMBuktK=LkAA@mail.gmail.com>
Subject: Re: save all inputs automatically
From: Alexander Gabriel <alex@barbalex.ch>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf307f33ec3e18de04ab203c84

--20cf307f33ec3e18de04ab203c84
Content-Type: text/plain; charset=UTF-8

well, I implemented it with just the regular savedoc for every change event.
Works beautifully in the pc-browser.
Not sure, if it will be fast enough on the mobile though.
I will look into update functions if it turns out too slow.
Thanks for your help.
Alex


2011/8/22 Peter Nolan <peterwnolan@gmail.com>

> Hey Alex,
>
> Your question is a great question, and unfortunately a hard one to answer
> without more knowledge of your particular application, data structure and
> intended usage.
>
> Unfortunately I couldn't access your application without making an account
> -
> and i don't speak german so i couldn't fill out the fields correctly :/
>
> But in regards to your question, there are incredible amount of ways to
> handle your problem.  Keeping track of revisions with a particular document
> shouldn't be a problem (just store the returned _rev key somewhere) and
> update accordingly.
>
> Alternatively, you could bypass the whole _rev check with a clever update
> function.  (if you need help with these feel free to ask)
>
> However, it sounds like data usage is your biggest concern (im assuming
> this
> is a mobile application).  In which case, have you thought about doing a
> setTimeout on field changes?
> for example, when a field changes, delay the sending of the update by a
> minute.  If a new field changes, clear the previous timeout, and start a
> new
> '1 minute countdown' to send the data.  The data sent should only be the
> keys the change in the document, and it should call an update function.
>  This will cut down on data usage as well (it won't send the WHOLE
> document,
> just what needs to be updated).
>
>
> But honestly, if data usage is not a concern, couchdb is more than up to
> the
> task for handling A LOT of document revisions.
>
> hope that helped somewhat,
>
> -Pete
>

--20cf307f33ec3e18de04ab203c84--