couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Gabriel <>
Subject Re: view crashes chrome
Date Wed, 06 Mar 2013 15:42:49 GMT
phew. What great help!

O.k., so basically I do all I did in memory on the server inside the list
function. I'm not used to list functions (which is kind of obvious by no
I'm afraid), so I'll get my head down and work on this. But it does sound
as if it should work.

Guys: You've earned a beer. Unless someone of you passes by Z├╝rich in
Switzerland I'm afraid a virtual one will have to do... (and if so: do
contact me!)

Thanks a lot!


Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64

2013/3/6 Matthieu Rakotojaona <>

> On Tue, Mar 5, 2013 at 5:22 PM, Alexander Gabriel <>
> wrote:
> > Seems like this really is a Chrome issue and has nothing to do with
> > CouchDb.
> I think downloading the whole documents for each processing is a bad
> idea, whatever the browser. You should try to better think your views;
> Here are some simple thoughts on how to do it.
> Basically, you have a document with multiple fields. I'll take [0] as
> an example doc and build upon it.
> (I have a question first: Why do you have 3 similar structures (I'm
> talking about CSCF(2009), ZH Artengruppen and ZH GIS). When the user
> wants a document, do you consider each of those as being different, or
> should the 3 be merged and seen as 1 document in the output ?)
> The view you will need will look like this:
> for each doc:
>    for each unitary output doc:  -> if the 3 docs are counted as 3
> different ones
>       for each field in Felder:
>            emit(field, null)
> This will give you a huge list of all the fields available for each
> document. You will then retrieve it from the client; use a reduce
> function (like _count) to group the fields if they are similar.
> You now have a list of all possible fields on your client. You can
> build the filter panel with this (ie you know what fields you can
> filter from), and you can also prefill the export panel.
> Now, the user can select the fields he wants to use as a filtering.
> Don't send anything to the server yet ! Just build a list of all the
> fields you want to keep. In parallel, you can also build the list of
> fields you want to export in the appropriate panel.
> Next step is to use a _list function to retrieve the documents that
> have all the fields (and, if needed, transform to csv also in the
> _list function). This _list function would accept a filter_list and an
> export_list parameters, the first one being the fields a doc must have
> to be exported, and the second one the list of fields to be exported.
> You can then convert your documents and send them back to the client.
> [0]
> --

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