You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Adam Groves <ad...@gmail.com> on 2008/11/18 13:27:35 UTC
View with incremental counter
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
Re: View with incremental counter
Posted by Paul Davis <pa...@gmail.com>.
Counters like this won't work. Your map function *must* return the
exact same output for identical inputs. Imagine you generate the view
once. Then edit a document. When it goes back through the map view
your function would give it a new counter. Assuming your documents are
edited in a non-deterministic order you won't be able to rely on the
counter to mean anything.
The only thing you could *almost* but not quite rely on it for would
be to get the list of documents in the order of their last edit. And
when I say almost, I mean it'll never work. But luckily there's
_all_docs_by_seq which does exactly that.
HTH,
Paul
On Tue, Nov 18, 2008 at 8:14 AM, Adam Groves <ad...@gmail.com> wrote:
> yeah but then my counter is still tied to the age of the document. Say
> I'd like to return a list of documents sorted by name.
>
> I'd have a view like this:
>
> count = 0;
> function(doc) {
> if(doc.type == "document") {
> count = count + 1
> emit(doc.name, count);
> }
> }
>
> I then create 4 documents in this order: Doc2, Doc3, Doc1, Doc4.
>
> The above view would give me the following results:
> Key Value
> -------------------
> Doc1 2
> Doc2 4
> Doc3 3
> Doc4 1
>
> Which is not what I'm after.
>
> 2008/11/18 Ulises <ul...@gmail.com>:
>> That's what I thought. The output is definitely sorted by key, but the
>>> document with a 'count' of one is in the middle of my results.
>>>
>>> I just tried this view for debugging:
>>>
>>> count = 0;
>>> function(doc) {
>>> if(doc.type == "document") {
>>> count = count + 1
>>> emit(doc._id, [count, doc.updated_at]);
>>> }
>>> }
>>>
>>> and it turns out that the document with a count of 1 is the most
>>> recently updated document.
>>>
>>
>> But isn't the signature of the emit fn emit(key, value)? Wouldn't it make
>> more sense then to emit([doc._id, count], some_value) however even then it'd
>> end up sorted only by doc._id. Perhaps emit([count, doc._id], some_value)
>> would do the trick.
>>
>> U
>>
>
Re: View with incremental counter
Posted by Adam Groves <ad...@gmail.com>.
yeah but then my counter is still tied to the age of the document. Say
I'd like to return a list of documents sorted by name.
I'd have a view like this:
count = 0;
function(doc) {
if(doc.type == "document") {
count = count + 1
emit(doc.name, count);
}
}
I then create 4 documents in this order: Doc2, Doc3, Doc1, Doc4.
The above view would give me the following results:
Key Value
-------------------
Doc1 2
Doc2 4
Doc3 3
Doc4 1
Which is not what I'm after.
2008/11/18 Ulises <ul...@gmail.com>:
> That's what I thought. The output is definitely sorted by key, but the
>> document with a 'count' of one is in the middle of my results.
>>
>> I just tried this view for debugging:
>>
>> count = 0;
>> function(doc) {
>> if(doc.type == "document") {
>> count = count + 1
>> emit(doc._id, [count, doc.updated_at]);
>> }
>> }
>>
>> and it turns out that the document with a count of 1 is the most
>> recently updated document.
>>
>
> But isn't the signature of the emit fn emit(key, value)? Wouldn't it make
> more sense then to emit([doc._id, count], some_value) however even then it'd
> end up sorted only by doc._id. Perhaps emit([count, doc._id], some_value)
> would do the trick.
>
> U
>
Re: View with incremental counter
Posted by Ulises <ul...@gmail.com>.
That's what I thought. The output is definitely sorted by key, but the
> document with a 'count' of one is in the middle of my results.
>
> I just tried this view for debugging:
>
> count = 0;
> function(doc) {
> if(doc.type == "document") {
> count = count + 1
> emit(doc._id, [count, doc.updated_at]);
> }
> }
>
> and it turns out that the document with a count of 1 is the most
> recently updated document.
>
But isn't the signature of the emit fn emit(key, value)? Wouldn't it make
more sense then to emit([doc._id, count], some_value) however even then it'd
end up sorted only by doc._id. Perhaps emit([count, doc._id], some_value)
would do the trick.
U
Re: View with incremental counter
Posted by Adam Groves <ad...@gmail.com>.
That's what I thought. The output is definitely sorted by key, but the
document with a 'count' of one is in the middle of my results.
I just tried this view for debugging:
count = 0;
function(doc) {
if(doc.type == "document") {
count = count + 1
emit(doc._id, [count, doc.updated_at]);
}
}
and it turns out that the document with a count of 1 is the most
recently updated document.
2008/11/18 Ulises <ul...@gmail.com>:
>> 62, 61, 22, 19. I'm not quite sure what's going on here - any ideas
>> how the order is being set here?
>
> Aren't the rows ordered by doc._id in this case? AFAIK (key, value)
> pairs are ordered by key so perhaps emit(count, doc._id) might be more
> appropriate.
>
> I could be completely wrong here though :)
>
> U
>
Re: View with incremental counter
Posted by Ulises <ul...@gmail.com>.
> 62, 61, 22, 19. I'm not quite sure what's going on here - any ideas
> how the order is being set here?
Aren't the rows ordered by doc._id in this case? AFAIK (key, value)
pairs are ordered by key so perhaps emit(count, doc._id) might be more
appropriate.
I could be completely wrong here though :)
U
Re: View with incremental counter
Posted by Chris Anderson <jc...@apache.org>.
> Ben Browning wrote:
>>
>> I have several views that actually include some javascript libraries
>> inline within the view outside of my map function (date.js for
>> example).
I've been doing that also, and it seems to work pretty well. I haven't
benchmarked to see if the extra code slows it down, but I know giant
map functions don't break anything. (I tend to include my inline code
within my view function, but I expect Spidermonkey can still optimize
it.)
--
Chris Anderson
http://jchris.mfdz.com
Re: View with incremental counter
Posted by Jedediah Smith <je...@silencegreys.com>.
Perhaps design docs could be allowed to provide init functions which
would be passed to the view server whenever the view server is
(re)started or the design doc is updated?
The view server would maintain a distinct, persistent sandbox for each
design doc (or however else you want to partition it) and the id of said
design doc would have to be passed with view protocol calls, if it isn't
already.
To enforce the map/reduce semantic requirements, the view server could
make the environment immutable for map/reduce calls and unlock it for
init calls.
Ben Browning wrote:
> I have several views that actually include some javascript libraries
> inline within the view outside of my map function (date.js for
> example). So, hopefully any sort of sandbox functionality would take
> this use-case into account.
>
> - Ben
>
Re: View with incremental counter
Posted by Ben Browning <be...@gmail.com>.
I have several views that actually include some javascript libraries
inline within the view outside of my map function (date.js for
example). So, hopefully any sort of sandbox functionality would take
this use-case into account.
- Ben
Re: View with incremental counter
Posted by Damien Katz <da...@apache.org>.
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 <da...@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
>>>> <je...@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
>>>>>>
>>
>>
Re: View with incremental counter
Posted by Paul Davis <pa...@gmail.com>.
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 <da...@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
>>> <je...@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
>>>>>
>
>
Re: View with incremental counter
Posted by Damien Katz <da...@apache.org>.
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
>> <je...@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
>>>>
Re: View with incremental counter
Posted by Damien Katz <da...@apache.org>.
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
>> <je...@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
>>>>
Re: View with incremental counter
Posted by Jedediah Smith <je...@silencegreys.com>.
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
> <je...@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
>>>
>
>
>
Re: View with incremental counter
Posted by Jedediah Smith <je...@silencegreys.com>.
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
> <je...@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
>>>
>
>
>
Re: View with incremental counter
Posted by Benjamin Nortier <bj...@gmail.com>.
I would imagine that it's not very easy if you want to retain the
ability to instantiate objects outside the function.
But I'm no expert :)
Ben
On Tue, Nov 18, 2008 at 2:59 PM, Paul Davis <pa...@gmail.com> wrote:
> If this is easy and you see an implementation, I think it'd be a great
> addition to force the sand boxing of individual functions.
>
> That said, I don't know much about the JS internals so I'm not sure
> how hard it would be to auto detect what might cause side effects
> outside the function and what wouldn't. I've stuck largish objects
> outside the function itself on the assumption that they'll only be
> instantiated once as opposed to once per document.
>
> I have absolutely no idea if that's even necessary though.
>
> Paul
>
> On Tue, Nov 18, 2008 at 9:51 AM, Benjamin Nortier <bj...@gmail.com> 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
>> <je...@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
>>>>
>>>
>>
>>
>>
>> --
>> Benjamin Nortier
>> e: bjnortier@gmail.com
>> c: +44 (0)778 946 1959
>> msn: bjnortier@mail.com
>> gtalk: bjnortier@gmail.com
>>
>
--
Benjamin Nortier
e: bjnortier@gmail.com
c: +44 (0)778 946 1959
msn: bjnortier@mail.com
gtalk: bjnortier@gmail.com
Re: View with incremental counter
Posted by Paul Davis <pa...@gmail.com>.
If this is easy and you see an implementation, I think it'd be a great
addition to force the sand boxing of individual functions.
That said, I don't know much about the JS internals so I'm not sure
how hard it would be to auto detect what might cause side effects
outside the function and what wouldn't. I've stuck largish objects
outside the function itself on the assumption that they'll only be
instantiated once as opposed to once per document.
I have absolutely no idea if that's even necessary though.
Paul
On Tue, Nov 18, 2008 at 9:51 AM, Benjamin Nortier <bj...@gmail.com> 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
> <je...@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
>>>
>>
>
>
>
> --
> Benjamin Nortier
> e: bjnortier@gmail.com
> c: +44 (0)778 946 1959
> msn: bjnortier@mail.com
> gtalk: bjnortier@gmail.com
>
Re: View with incremental counter
Posted by Benjamin Nortier <bj...@gmail.com>.
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
<je...@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
>>
>
--
Benjamin Nortier
e: bjnortier@gmail.com
c: +44 (0)778 946 1959
msn: bjnortier@mail.com
gtalk: bjnortier@gmail.com
Re: View with incremental counter
Posted by Jedediah Smith <je...@silencegreys.com>.
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
>