couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Gabriel <a...@barbalex.ch>
Subject Re: view crashes chrome
Date Mon, 04 Mar 2013 14:38:32 GMT
using 'limit' would limit what I get, right?
Trouble is: I need all the data.
Am I fetching too much data? What would limit the amount of data the view
can fetch?




***********************************************************



Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64
alex@barbalex.ch
www.barbalex.ch



2013/3/4 Kevin R. Coombes <kevin.r.coombes@gmail.com>

> Actually, you are probably better off use "startkey" and "limit" rather
> than "skip".
>
>
> On 3/4/2013 12:11 AM, Anthony Ananich wrote:
>
>> You probably need to use 'skip' and 'limit'
>> http://wiki.apache.org/**couchdb/HTTP_view_API#**Querying_Options<http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options>
>>
>> On Mon, Mar 4, 2013 at 2:54 AM, Alexander Gabriel<alex@barbalex.ch>
>>  wrote:
>>
>>> I have this view :
>>> function(doc) {
>>> if (doc.Gruppe&&  doc.Gruppe === "Flora"&&  doc.Typ&&
 doc.Typ ===
>>>
>>> "Objekt") {
>>>   emit ([doc._id, doc._rev]);
>>> }
>>> }
>>>
>>> It fetches 7900 documents with about 65 MB.
>>>
>>> When I call it (from javascript) without the all_docs option, it runs
>>> o.k.
>>> With the all_docs option it crashes Chrome but not Firefox (both newest
>>> versions).
>>>
>>> I've isolated the crash to this line of code:
>>> $db.view('artendb/flora?**include_docs=true"});
>>>
>>> I'v created a view that directly fetches all docs:
>>> function(doc) {
>>> if (doc.Gruppe&&  doc.Gruppe === "Flora"&&  doc.Typ&&
 doc.Typ ===
>>>
>>> "Objekt") {
>>> emit ([doc._id, doc._rev], doc);
>>> }
>>> }
>>> It runs without problems in futon.
>>>
>>> I've tested a bunch of the documents contained in the view on
>>> http://jsonlint.com and they were all o.k.
>>>
>>> Is there a way to lint the entire 65 MB of data?
>>> What else could cause the crash in chrome?
>>> What would you do to crush this bug?
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message