Views in production

Couchbase Server
1

Hi,

What are the benefits of moving views into production ?

2

@itay

Development views only work on a small portion of the dataset; they allow you to develop the view without impacting any users of the view.

-Jeff

3

Let me rephrase:
What are the benefits of views into production compared to using view in development with full_set=true flag ?

4

As far as I’m aware, there’s no technical difference between the results of the two, if you were to do that, although I think passing full_set=true forces a refresh of the view rather than using the indexed results. Development views are not auto-updated during a rebalance operation.

I think the biggest issue with using development views in that way is the security aspect of being able to change them through the web UI very easily. However, if your app is in development then you could do it (although you need a different URL to access them and each SDK might handle that differently) - just be aware that performance won’t be realistic. You can also create production views directly via the REST API, which might be an option in this case as well.

5

Thanks,
If a development view refreshes the result on every call then it would take a long time to build the result every time and it actually will not be a view, but rather a query, and this is not what I am experiencing.

6

@daves is generally correct. One other thing production views do for you is update if there are a sufficient number of mutations in a short period of time, even without being queried (IIRC, 5000 in a 30s period or something like that, check the docs to be sure).

I’d recommend using production views for exactly what Dave mentions though, the workflow aspect of being able to modify it later. If the dev and production version of the view are the same, there is zero cost to having both of them around. Eventually, you’ll want to modify the view I expect.

7

@ingenthr
Can you please guide me to the relevant docs ?

If there is no cost of having both dev and prod views, then why have both if I eventually modify it ?

I also don’t completely understand the performance penalty of using the dev view ?

Thanks

8

Sure @itay, the best doc to read is the views section in general, but this one on production views gives the workflow.

The reason you may have both is that there will be additional cost once they diverge. Since with a development view you can target a deterministic subset only, the cost isn’t that high when that divergence happens. And, since you can materialize the view fully before atomically swapping out the production view with the new development view, you can continue to keep that cost low and test against development views.