Hi, (tl;dr: How to avoid re-creating the view
index on read if design document modified)
we aren't yet in production with our service that is built on top of
CouchDB.
But in our alpha stages we have already run into problems regarding
design document deployment and view sequence updates.
The simplified design document structure is something like:
_design/customers
views
all
by_sales_person
etc
_design/products
views
all
active
etc
Now the problem is, we want to evolve quickly and deploy daily to
"production".
Let's say I add a new view to _design/products to support our upcoming
features - let's assume it's called "in_stock" - and push the design
document to "production".
Now when existing users try to fetch listing of their products, they
have to wait for the view update for design doc _design/products.
The real question here is: How can I push to the same design document
frequently without affecting the response times for our users.
I know there are a few options including:
a) Use new design documents for new views - makes the structure of
the application not that nice. We are expecting tens or hundreds of views
b) Deploy only at night and make sure to re-create view indices -
we are using filtered replication, we would need to 1) have access to
all the databases 2) it's not optimal to deploy at night time and also
we are expecting activity 24/7
c) query views with stale=ok - this doesn't seem like a good thing
to do within a problem domain where real-time is the key thing to have..
The best suggestion I have gotten (from the great IRC-channel), is to
have two (or multiple) versions of every design document, and then in
application logic figure out which one to use. This way I could push the
design document, trigger view index update and then make the
applications use the new design document.
I can see some shortcomings with this approach, however, including:
a) this would have to be realtime, so either I would have to fetch
the design document to be used before every view query or then have some
404 -> figure out which view to query
b) or have multiple design document "versions" (like
_design/products_20111130) and hardcode the values in client
applications (webbrowser, native mobile clients, native desktop
clients). In the long run this will be horrible to manage..
c) no deployment tool supports this, so I would have to self write
the automation of deployment for this, not a big deal but still..
So, any other ideas or pointers how to accomplish this? There are so
many great features (with replicaton etc) with couchdb I wouldn't like
to have this single thing ruin it for me..
BR,
Niklas Närhinen