Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=GWe39QOojSjuI1ARXy1FYsDkcSv+gdS9eYfusbuXPNWsYmSWGCb9beMQc5X20+onR7
         cBx0ukibN/HLmOSsm+7+sDJ/dYELSNCYuxbsf01J8I6q6gvdE8YOca6j0L6vv6GTKa31
         edIUbLwc+xwNIRpMMaaNKBGhm6PKb/8f4dLDM=
Message-ID: <e282921e0810272048j18207643v95a9ed0a18018133@mail.gmail.com>
Date: Mon, 27 Oct 2008 20:48:59 -0700
From: "Chris Anderson" <jchris@apache.org>
Sender: jchris@gmail.com
To: couchdb-user@incubator.apache.org
Subject: Re: Getting only updates from a view
In-Reply-To: <64a10fff0810271954p369b9a49w677084772de187d5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <83FAD073-9DD0-495C-B70D-C587CA3563FD@msc-mobile.com>
	 <27d8d0930810260736g58acbd4bn61c417d3e1fd3b95@mail.gmail.com>
	 <E47B5491-BAF9-49ED-B736-C85D838DA1DC@mac.com>
	 <64a10fff0810271039w1a561c3djf75b7ffbdd182c35@mail.gmail.com>
	 <4AC6C22D-55D8-4C39-8542-02F6525E4954@msc-mobile.com>
	 <64a10fff0810271954p369b9a49w677084772de187d5@mail.gmail.com>

Plus 1 for the idea of sandboxing each client application in its own database.

If you really are going to allow end users to write views, you should
at least read and understand the security implication of this:
http://peter.michaux.ca/article/8069

It sounds like your application could be a strong fit for couchdb, but
it might take some thought to figure out how best to use it.

Cheers,
Chris

On Mon, Oct 27, 2008 at 7:54 PM, Dean Landolt <dean@deanlandolt.com> wrote:
> Wow. That's a wholelotta client apps. In this case yeah, there may not be a
> great way to generalize the views since it sounds like you don't even
> control them, but from the little I've been able to glean, you may want to
> take some measures to sandbox this view creation somewhat. If all views go
> into the same design document, one view's change results in all views being
> rebuilt -- probably not what you want. So perhaps each client should get
> their own design doc where they can create their views...
>
> But I'd go a little further and suggest that if you have that many clients
> who need ultimate control over views, perhaps you may want to rethink the
> architecture. Letting clients design your views could get a little hairy --
> one rogue view could take down your whole system. I don't know anything
> about the data you're keeping, but perhaps you could expose it certain ways
> useful to as many clients as possible, but punt on all that processing. Let
> the clients deal with that -- and for those that really need their own
> views, just replicate them an instance of the db and they can add all the
> views they want.
>
>
> On Mon, Oct 27, 2008 at 1:58 PM, Julien Guimont <
> julien.guimont@msc-mobile.com> wrote:
>
>> Hello,
>>
>> That is an option i do not completely understand right now. If there are
>> blog post on the subject that would be great!
>>
>> My usage scenario is the following:
>> I have many client applications (1000-10000)
>> They send to my application server what they want as a data set (a view)
>> The application server adds the view to the design document, execute it and
>> return the result to the client
>> Upon document updates, the application server refresh the views and inform
>> the client of new data (is any)
>>
>> Am I going in a good direction?
>>
>> Thank you,
>> Julien.
>>
>>
>> On 27-Oct-08, at 1:39 PM, Dean Landolt wrote:
>>
>>  On Sun, Oct 26, 2008 at 10:08 PM, Julien Guimont <
>>> julien.guimont@msc-mobile.com> wrote:
>>>
>>>  Thanks for the answer, pretty obvious.
>>>>
>>>> I would have 1000 to 10000 views to update periodically upon document
>>>> updates. There would be 5-10 updates a second and more than 500k
>>>> documents.
>>>> Will couchdb scale in that case?
>>>>
>>>> Thank you,
>>>> Julien.
>>>>
>>>
>>>
>>> What kind of use case would require 10000 views? Couldn't there a way to
>>> generalize some of your view functions with compound keys to give you what
>>> you need in a *much* smaller number of views?
>>>
>>
>>
>


-- 
Chris Anderson
http://jchris.mfdz.com