[JCBC-63] add APIs for creating and deleting design documents for CBS 2.0 Created: 08/Jun/12  Updated: 29/Nov/12  Resolved: 29/Nov/12

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1dp
Fix Version/s: 1.1-beta
Security Level: Public

Type: New Feature Priority: Blocker
Reporter: Dipti Borkar Assignee: Michael Nitschinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
depends on JCBC-147 Rename getViews() to getDesignDocument() Resolved

There are have been several requests from users to have APIs to create and delete views from the Java (and other) SDKs.
This is a MUST have for some customers and needs to be a part of the Client SDK we release prior to Beta.

Comment by Matt Ingenthron [ 08/Jun/12 ]
I'm in agreement. One question is do we also want this API to be involved in the view materialization process. I think the answer is probably yes, but this can be complicated since it can potentially take a very long time with little feedback.
Comment by Dipti Borkar [ 08/Jun/12 ]
When you say View materialization process? what exactly do you mean? given that index building happens at query time, I don't think so.

However, there are other APIs that may be more interesting to have. explicitly triggering compaction, configuring min time duration / min # of mutations to trigger index building.
Comment by Matt Ingenthron [ 24/Jul/12 ]
What I mean by the view materialization process is that we, in the web console, have this flow where we advise people to take their "dev_aview" and run a full cluster dataset query on it before publishing it to production. This way, when it's published as "aview", the view will have been mostly materialized. It's a nice thing for updating a view.

The reason this is complicated is that it's an HTTP request that may go for a very long, long time. I can think of a way around it (poll it with a timeout until it's fast), but it's suboptimal unless we start querying view materialization progress.
Comment by Michael Nitschinger [ 26/Aug/12 ]
Matt, what if we wait for it in a separate thread and return with a future when it's done? We just need to make the user aware that it can take a long time, and if they add a view for development that they'd have to publish it separately.

Another idea would be to make the "let's do a full dataset query" optional when the view gets published since someone may want to do that later or from the web-ui.
Comment by Matt Ingenthron [ 26/Aug/12 ]
Michael: that's effectively what we do right now since it's the query against the view that takes a long time. The design document management operations do not. The view requests are not quite done asynchronously, that's true.

The main point I was raising was that the Web Console provides for functionality to execute a view before pushing it in production and workflow to take it from "dev_thing" to "thing" knowing that the view has been materialized. In the SDK, I don't think we'll try to replicate that workflow, but the same functionality is definitely available.
Comment by Michael Nitschinger [ 05/Oct/12 ]
Just to keep everyone updated, I started developing it here: http://review.couchbase.org/#/c/21380/
Comment by Michael Nitschinger [ 29/Nov/12 ]
this has finally been merged to master.
Generated at Fri Jul 11 17:56:39 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.