couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Gabriel <>
Subject Re: How to give user feedback on view progress
Date Sat, 04 May 2013 21:13:02 GMT
Thanks for the helpful clues, Dave!

The information imported in many cases adds objects to arrays in existing
documents (in rare and well defined cases new documents would be created).
I'm not 100% sure why indexes take a while to update. Probably because some
views use information from these objects in their keys and these views will
have to be updated, although most views don't need to be updated. Does this
make sense?

As the views needed to access the updated documents don't contain
information from the updated arrays, stale=update_after would probably
work, if I no other views would be called in the meantime. Unfortunately
accessing the new documents calls other views also, every time a document
is presented in the ui. It's probably not feasible to control all these
unless they are always run with the stale option. Which may be a good idea.
I'll have to think through the implications.

It would be hard though to decide when the update shall take place because
the user importing new data would be the one most likely to depend on the
views accessing the objects in the arrays and specifically the new
information in them, likely just after importing the last batch of data.

Which makes me feel I should show this user the progress of updating the
views which means accessing _active_tasks.

Looks obvious that you can compare "changes_done" with "total_changes" to
show the progress.
It even looks like "progress" is exactly this in percent. Very handy!
There's no way around having admin rights to get this information though,
is there?

The less informative way without needing admin rights would be to wait
until the next view returns data and just ask the user to wait until he is
told the process has finished.

Another thing just came to my mind:
If views update, all users will be blocked. Only very few users use the
views that need to be updated though.
So what if I put these views into a different design document? Wouldn't
this prevent all the other views (in the other design doc) from being
temporarily blocked?
If true, this would also enable the importing user to check if the import
worked as planned directly after importing.
He'd only have to wait if he decides to do something that uses one of the
updating vies soon after. Which would happen a lot less often.
What would the side effects be of putting some views into a different
design doc? (please remember, I'm just a biologist, not a programmer - a

So my options are:
1. Nice feedback showing progress using _active_tasks with admin rights
2. Say "please wait for an unknown time" and tell the user when the views
are updated
3. Placing the views that use information from the imported objects into a
different design doc and either ignoring blocked users or using one of the
two previous options to catch this rare case




Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64

2013/5/4 Dave Cottlehuber <>

> On 4 May 2013 21:23, Alexander Gabriel <> wrote:
> > O.k., I'll look this up. Thanks!
> >
> > In one of my couchapps people upload data and then it can take a while
> for
> > the index to catch up. No data has to be downloaded then, so that case is
> > all about following the updating of the index. And as I present links so
> > the Users can check the result of the upload, I should also tell them
> when
> > they can do this.
> >
> > I'd need a couchdb specific method for that, probably?
> Some of these might be useful;
> After the upload is complete, query the view with stale=update_after,
> to trigger a view update. You can use &limit=0 to get an instant
> return and not have to transmit any data back.
> Or you can query the view and leave off the stale= part, when that GET
> returns, your view is up to date.
> Or if this user is the only one writing to the DB (classic local couch
> style with replication elsewhere) you *could* use
> update_seq=true&stale=ok and compare the update_seq with that of the
> DB itself.
> You can also see in _active_tasks the current state of a view being built;
>     {
>         "changes_done": 9346,
>         "database": "testy",
>         "design_document": "_design/simpleform",
>         "pid": "<0.31025.15>",
>         "progress": 41,
>         "started_on": 1367697289,
>         "total_changes": 22454,
>         "type": "indexer",
>         "updated_on": 1367697741
>     }
> The first 2 options are probably your best bet.
> A+
> Dave

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