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 noob!) 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 correct? Alex *********************************************************** Alexander Gabriel Wiesenstrasse 22 8800 Thalwil 079/ 372 51 64 [email protected] www.barbalex.ch 2013/5/4 Dave Cottlehuber <[email protected]> > On 4 May 2013 21:23, Alexander Gabriel <[email protected]> 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. > > http://wiki.apache.org/couchdb/HTTP_view_API#View_Generation_Options > > A+ > Dave >
