Hi Zachary and thanks for answering!
I admit my lack of deep knowledge on couchdb internals here, but how
does couchdb know that it's the same design doc with different name? How
are the view indices stored? What I'm trying to find out, how does it
know it has been already indexed with a different name earlier..
Niklas
30.11.2011 17.23, Zachary Zolton kirjoitti:
Niklas,
The best way I have found to deal with this is to add these steps to
my deployment procedures:
* push the new design doc as _design/your_ddoc_name-prime
* query any view from that _design/your_ddoc_name-prime with ?limit=1
* wait for the view query results
* push the new design doc again as _design/your_ddoc_name
* finally, switch over to the new version of your application code
This doesn't require any special knowledge in your clients, since they
always query _design/your_ddoc_name.
I've used this approach several times and it works like a charm. Yes,
you'll have to write a small script, but it's really not that bad.
--Zach
2011/11/30 Niklas Närhinen<[email protected]>:
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
