couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Smith (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2037) view unavailability on production design docs
Date Sun, 26 Jan 2014 03:26:37 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882159#comment-13882159
] 

Jason Smith commented on COUCHDB-2037:
--------------------------------------

Interestingly, CouchDB already has that view data available, even when you replace the design
document. You must explicitly do a view cleanup to remove those files from disk: http://docs.couchdb.org/en/latest/api/database/compact.html?highlight=cleanup#post--db-_view_cleanup

So this implementation is not as difficult as it may seem.

A very quick and dirty fix could be a hidden or obscure URL where you could query a view directly
by its hash value (the MD5 of the ddoc.views value, i.e. the name of the file on disk with
the .view suffix), and couch could just trust that you know what you are talking about and
attempt to query that file.

Standard "thinking aloud" disclaimer applies :)

> view unavailability on production design docs
> ---------------------------------------------
>
>                 Key: COUCHDB-2037
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2037
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: JavaScript View Server
>            Reporter: Isaac Z. Schlueter
>
> It can take a very long time to generate views for a large database.  If you have an
application that relies on those views, even if performance is acceptable, it is generally
a serious problem if something causes the views for that design doc to no longer be available.
 This gets especially tricky if a new view is added or modified, as then all view data is
thrown away and regenerated, causing your website or app to be unavailable for hours at a
time.
> To work around this problem, I've taken to the following work flow:
> 1. PUT the new design doc to /db/_design/scratch
> 2. Load a view from /db/_design/scratch
> 3. Once view generation on _design/scratch finishes, send an http COPY request to move
the _design/scratch to _design/app.
> This mostly works pretty well.  However, if you have jobs that copy couchdb documents
from one place to another, it can be very easy to accidentally trigger a view regeneration
and cause your website or app to go down.  (Qv today's npmjs.org outage.)
> I would love it if there was a way to say, "NEVER make the views of _design/app unavailable,
even if they are temporarily out of date".  I can imagine a few ways that this could be accomplished:
> 1. PUTs to the specified design doc fail if they modify the "views" member.
> 2. COPYs to the specified design doc fail if the COPY source does not have a full set
of pre-generated views.
> 3. Views for the specified design doc are always done in the background, and stale=ok
is assumed for all requests.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message