Uploaded image for project: 'Couchbase Java Client'
  1. Couchbase Java Client
  2. JCBC-63

add APIs for creating and deleting design documents for CBS 2.0

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1dp
    • Fix Version/s: 1.1-beta
    • Component/s: Core
    • Security Level: Public
    • Labels:
      None

      Description

      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.

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          dipti Dipti Borkar created issue -
          Hide
          ingenthr Matt Ingenthron added a comment -

          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.

          Show
          ingenthr Matt Ingenthron added a comment - 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.
          Hide
          dipti Dipti Borkar added a comment -

          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.

          Show
          dipti Dipti Borkar added a comment - 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.
          Hide
          ingenthr Matt Ingenthron added a comment -

          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.

          Show
          ingenthr Matt Ingenthron added a comment - 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.
          ingenthr Matt Ingenthron made changes -
          Field Original Value New Value
          Fix Version/s 1.1beta [ 10370 ]
          Fix Version/s 1.1 [ 10274 ]
          Hide
          daschl Michael Nitschinger added a comment -

          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.

          Show
          daschl Michael Nitschinger added a comment - 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.
          Hide
          ingenthr Matt Ingenthron added a comment -

          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.

          Show
          ingenthr Matt Ingenthron added a comment - 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.
          daschl Michael Nitschinger made changes -
          Assignee Matt Ingenthron [ ingenthr ] Michael Nitschinger [ daschl ]
          Hide
          daschl Michael Nitschinger added a comment -

          Just to keep everyone updated, I started developing it here: http://review.couchbase.org/#/c/21380/

          Show
          daschl Michael Nitschinger added a comment - Just to keep everyone updated, I started developing it here: http://review.couchbase.org/#/c/21380/
          daschl Michael Nitschinger made changes -
          Issue Type Improvement [ 4 ] New Feature [ 2 ]
          daschl Michael Nitschinger made changes -
          Link This issue depends on JCBC-147 [ JCBC-147 ]
          Hide
          daschl Michael Nitschinger added a comment -

          this has finally been merged to master.

          Show
          daschl Michael Nitschinger added a comment - this has finally been merged to master.
          daschl Michael Nitschinger made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          ingenthr Matt Ingenthron made changes -
          Workflow jira [ 17686 ] Couchbase SDK Workflow [ 38345 ]

            People

            • Assignee:
              daschl Michael Nitschinger
              Reporter:
              dipti Dipti Borkar
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Gerrit Reviews

                There are no open Gerrit changes