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 <[EMAIL PROTECTED]>
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
<[EMAIL PROTECTED]> 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