That, and sealing the context too, to prevent these sorts of things.

-Damien

On Nov 18, 2008, at 2:45 PM, Paul Davis wrote:

> Wasn't that the document sealing to prevent maps from interfering with
> each other?
>
> On Tue, Nov 18, 2008 at 2:35 PM, Damien Katz <damien@apache.org>  
> wrote:
>> Spidermonkey's sandboxing capabilities vary release to release. As  
>> I recall,
>> we had full sandboxing working with earlier releases, but something  
>> changed
>> in 1.7 and we took it out.
>>
>> -Damien
>>
>> On Nov 18, 2008, at 2:30 PM, Jedediah Smith wrote:
>>
>>>
>>> Grasping the concepts involved in map/reduce might end up being a
>>> significant hurdle to CouchDB adoption so I would encourage  
>>> features that
>>> assist in that regard. Sandboxing might also be necessary to enforce
>>> whatever is ultimately CouchDB's security model.
>>>
>>> Spidermonkey must have sandboxing capabilities if it runs the  
>>> javascript
>>> for both the Firefox browser and the web pages it loads.
>>>
>>> Paul's case of caching large objects is something to consider (and a
>>> reason my previous email was not strictly correct) but could  
>>> perhaps be
>>> handled more formally or left to custom view servers.
>>>
>>> Benjamin Nortier wrote:
>>>>
>>>> Should CouchDB not restrict defining state outside the map  
>>>> function?
>>>> I.e. you should not be able to declare a counter outside the  
>>>> function?
>>>> On Tue, Nov 18, 2008 at 1:42 PM, Jedediah Smith
>>>> <jedediah@silencegreys.com> wrote:
>>>>>
>>>>> You can't maintain a state across calls to map functions in this  
>>>>> way.
>>>>> Map
>>>>> functions can be called in any order or in parallel, any number  
>>>>> of times
>>>>> on
>>>>> a particular document and in completely separate environments.  
>>>>> They
>>>>> should
>>>>> not have any side effects or depend on any outside state.
>>>>>
>>>>> You should read up on Google's MapReduce and maybe functional
>>>>> programming in
>>>>> general in order to understand how CouchDB works.
>>>>>
>>>>> If you just want to number the results of your view, that can be  
>>>>> easily
>>>>> done
>>>>> by the calling code.
>>>>>
>>>>> Adam Groves wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've got the following view:
>>>>>>
>>>>>> count = 0;
>>>>>> function(doc) {
>>>>>> if(doc.type == "document") {
>>>>>> count = count + 1
>>>>>> emit(doc._id, count);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The idea is that I get a list of documents, each having a counter
>>>>>> value which is incremental. I expected the count values to come  
>>>>>> out in
>>>>>> order, but that isn't the case: my first few documents have  
>>>>>> values of
>>>>>> 62, 61, 22, 19. I'm not quite sure what's going on here - any  
>>>>>> ideas
>>>>>> how the order is being set here?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Adam Groves
>>>>>>
>>
>>