:8091/pools",
+ :bucket => 'bucket1',
+ :username => 'Administrator',
+ :password => 'password')
+```
+
+This next example demonstrates use of credentials in PHP:
+
+
+```
+:8091", "bucketname", "password", "user");
+ ?>
+```
+
+ uris = new LinkedList();
+
+ uris.add(URI.create("http://127.0.0.1:8091/pools"));
+
+ CouchbaseClient client = null;
+
+ try {
+
+ client = new CouchbaseClient(uris, "beer-sample", "");
+
+
+ // put your code here
+ client.shutdown();
+ } catch (Exception e) {
+ System.err.println("Error connecting to Couchbase: " + e.getMessage());
+ System.exit(0);
+ }
+
+
+
+```
+
+Here we create a list of URIs to different nodes of the cluster; for the sake of
+convenience we are working with a single node cluster. Then we connect to our
+bucket, which in this case is `beer-sample`.
+
+**Creating View Functions with an SDK**
+
+Couchbase SDKs provide all the methods you need to save, index, and query views.
+Imagine we want to get all the beer names out of our sample database. In this
+case, our map function would appear as follows:
+
+
+```
+function (doc, meta) {
+ if(doc.type && doc.type == "beer") {
+ emit(doc.name, null);
+ }
+}
+```
+
+At first, we import the Java SDK libraries that we need to work with views. Then
+we can create a design document based on the `DesignDocument` class and also
+create our view as an instance of the `ViewDesign` class:
+
+
+```
+import com.couchbase.client.protocol.views.DesignDocument;
+import com.couchbase.client.protocol.views.ViewDesign;
+
+ DesignDocument designDoc = new DesignDocument("dev_beer");
+
+ String viewName = "by_name";
+ String mapFunction =
+ "function (doc, meta) {\n" +
+ " if(doc.type && doc.type == \"beer\") {\n" +
+ " emit(doc.name);\n" +
+ " }\n" +
+ "}";
+
+ ViewDesign viewDesign = new ViewDesign(viewName,mapFunction);
+ designDoc.getViews().add(viewDesign);
+ client.createDesignDoc( designDoc );
+```
+
+In this case we create a design document named 'dev\_beer', name our actual view
+'by\_name' and store the map function in a String. We then create a a new view
+provide the constructor the name and function. Finally we add this view to our
+design document and store it to Couchbase Server with `createDesignDoc`.
+
+**Querying View from SDKs**
+
+At this point you can index and query your view. Be aware that when you first
+create a view, whether this in Couchbase Web Console, or via an SDK, the view is
+in development mode. You need to put the into production mode in order to query
+it:
+
+
+```
+import import com.couchbase.client.protocol.views.*;
+
+System.setProperty("viewmode", "development"); // before the connection to Couchbase
+
+// Create connection if needed
+
+View view = client.getView("beer", "by_name");
+Query query = new Query();
+query.setIncludeDocs(true).setLimit(20);
+query.setStale( Stale.FALSE );
+ViewResponse result = client.query(view, query);
+
+for(ViewRow row : result) {
+ row.getDocument(); // deal with the document/data
+}
+```
+
+Before we create a Couchbase client instance and connect to the server, we set a
+system property 'viewmode' to 'development' to put the view into production
+mode. Then we query our view and limit the number of documents returned to 20
+items. Finally when we query our view we set the `stale` parameter to FALSE to
+indicate we want to reindex and include any new or updated beers in Couchbase.
+For more information about the `stale` parameter and index updates, see [Index
+Updates and the Stale
+Parameter](http://www.couchbase.com/docs/couchbase-manual-2.1.0/couchbase-views-writing-stale.html).
+
+The last part of this code sample is a loop we use to iterate through each item
+in the result set. You can provide any code for handling or outputting
+individual results here.
+
+For more information about developing views in general, the follow resources
+describe best practices, and how indexing works on the server, along with other
+topics:
+
+ * [View Writing Best
+ Practice](http://www.couchbase.com/docs/couchbase-manual-2.1.0/couchbase-views-writing-bestpractice.html).
+
+ * [Views and Stored
+ Data](http://www.couchbase.com/docs/couchbase-manual-2.1.0/couchbase-views-datastore.html).
+
+ * [Development and Production
+ Views](http://www.couchbase.com/docs/couchbase-manual-2.1.0/couchbase-views-types.html).
+
+Hello from Hello from
+ "comments" : ["comment1_jchris_Hello_world", "comment2_kzeller_Hello_World"]
+}
+```
+
+The next document contains the first actual comment that is associated with the
+post. It has the key `comment_id` with the first value of
+'comment1\_dborkar\_Hello\_world'; this value serves as a reference back to the
+blog post it belongs to:
+
+
+```
+{
+ "comment_id": "comment1_dborkar_Hello_World",
+ "format": "markdown",
+ "body": "Awesome post!"
+}
+```
+
+The next example demonstrates our beer and breweries example as single and
+separate documents. If we wanted to use a single-document approach to represent
+a beer, it could look like this in JSON:
+
+
+```
+{
+ "beer_id": 10.0,
+ "name": "Hoptimus Prime",
+ "category": "North American Ale",
+ "style": "Imperial or Double India Pale Ale",
+ "brewery": "Legacy Brewing Co." : {
+ "address1" : "Easy Peasy St.",
+ "address2" : "Suite 4",
+ "city" : "Baltimore",
+ "state" : "Maryland",
+ "zip" : "21215",
+ "capacity" : 10000,
+ },
+ "updated": [2010, 7, 22, 20, 0, 20],
+ "available": true
+}
+```
+
+In this case we provide information about the brewery as a subset of the beer.
+But consider the case where we have more than one beer from the brewery, in this
+case:
+
+
+```
+{
+ "beer_id": 12.0,
+ "name": "Pleny the Hipster",
+ "category": "Wheat Beer",
+ "style": "Koelsch",
+ "brewery": "Legacy Brewing Co." : {
+ "address1" : "Easy Peasy St.",
+ "address2" : "Suite 4",
+ "city" : "Baltimore",
+ "state" : "Maryland",
+ "zip" : "21215",
+ "capacity" : 10000,
+ },
+ "updated": [2011, 8, 2, 20, 0, 20],
+ "available": true
+}
+```
+
+Here we are starting to develop duplicate information because we have the same
+brewery information in each beer document. In this case it makes sense to
+separate the brewery and beers as different documents and relate them through
+fields. The revised, separate beer document appears below. Notice we have added
+a new field to represent the brewery and provide the brewer id:
+
+
+```
+{
+ "beer_id": 10.0,
+ "name": "Hoptimus Prime",
+ "category": "North American Ale",
+ "style": "Imperial or Double India Pale Ale",
+ "brewery" : "leg_brew_10"
+ "updated": [2010, 7, 22, 20, 0, 20],
+ "available": true
+}
+```
+
+And here is the associated brewery as a separate brewery document. In this case,
+we may simplify the document structure since it is separate from the beer data,
+and provide all the brewery information at the same level:
+
+
+```
+{
+ "brewery_id" : "leg_brew_10",
+ "name": "Legacy Brewing Co.",
+ "address1" : "Easy Peasy St.",
+ "address2" : "Suite 4",
+ "city" : "Baltimore",
+ "state" : "Maryland",
+ "zip" : "21215",
+ "capacity" : 10000,
+}
+```
+
+
+#include
+#include
+
+static void error_callback(lcb_t instance,
+ lcb_error_t err,
+ const char *errinfo)
+{
+ fprintf(stderr, "Error %s: %s", lcb_strerror(instance, err),
+ errinfo ? errinfo : "");
+ exit(EXIT_FAILURE);
+}
+
+static void get_callback(lcb_t instance,
+ const void *cookie,
+ lcb_error_t error,
+ const lcb_get_resp_t *resp)
+{
+ if (error != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to retrieve \"");
+ fwrite(resp->v.v0.key, 1, resp->v.v0.nkey, stderr);
+ fprintf(stderr, "\": %s\n", lcb_strerror(instance, error));
+ } else {
+ fprintf(stderr, "Data for key: \"");
+ fwrite(resp->v.v0.key, 1, resp->v.v0.nkey, stderr);
+ fprintf(stderr, "\" is : ");
+ fwrite(resp->v.v0.bytes, 1, resp->v.v0.nbytes, stderr);
+ }
+}
+
+int main(void)
+{
+ struct lcb_create_st create_options;
+ lcb_t instance;
+ lcb_error_t err;
+
+ memset(&create_options, 0, sizeof(create_options));
+ create_options.v.v0.host = "myserver:8091";
+ create_options.v.v0.user = "mybucket";
+ create_options.v.v0.passwd = "secret";
+ create_options.v.v0.bucket = "mybucket";
+
+ err = lcb_create(&instance, &create_options);
+ if (err != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to create libcouchbase instance: %s\n",
+ lcb_strerror(NULL, err));
+ return 1;
+ }
+
+ /* Set up the handler to catch all errors! */
+ lcb_set_error_callback(instance, error_callback);
+
+ /*
+ * Initiate the connect sequence in libcouchbase
+ */
+ if ((err = lcb_connect(instance)) != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to initiate connect: %s\n",
+ lcb_strerror(NULL, err));
+ return 1;
+ }
+
+ /* Run the event loop and wait until we've connected */
+ lcb_wait(instance);
+
+ /*
+ * Set up a callback for our get requests
+ */
+ lcb_set_get_callback(instance, get_callback);
+
+ lcb_get_cmd_t cmd;
+ const lcb_get_cmd_t * const commands[1] = { &cmd };
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.v.v0.key = "foo";
+ cmd.v.v0.nkey = 3;
+
+ err = lcb_get(instance, NULL, 1, commands);
+ if (err != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to get: %s\n",
+ lcb_strerror(NULL, err));
+ return 1;
+ }
+
+ lcb_wait(instance);
+
+ lcb_destroy(instance);
+ exit(EXIT_SUCCESS);
+}
+```
+
+To compile this sample program, you must link to `libcouchbase` :
+
+
+```
+shell> gcc -o hellocb -lcouchbase hellocb.c
+```
+
+
+ * mininal.exe
+ */
+#include
+#include
+#include
+#include
+#include
+#ifdef _WIN32
+#define PRIu64 "I64u"
+#else
+#include
+#endif
+
+static void error_callback(lcb_t instance, lcb_error_t error, const char *errinfo)
+{
+ fprintf(stderr, "ERROR: %s (0x%x), %s\n",
+ lcb_strerror(instance, error), error, errinfo);
+ exit(EXIT_FAILURE);
+}
+
+static void store_callback(lcb_t instance, const void *cookie,
+ lcb_storage_t operation,
+ lcb_error_t error,
+ const lcb_store_resp_t *item)
+{
+ if (error == LCB_SUCCESS) {
+ fprintf(stderr, "STORED \"");
+ fwrite(item->v.v0.key, sizeof(char), item->v.v0.nkey, stderr);
+ fprintf(stderr, "\" CAS: %"PRIu64"\n", item->v.v0.cas);
+ } else {
+ fprintf(stderr, "STORE ERROR: %s (0x%x)\n",
+ lcb_strerror(instance, error), error);
+ exit(EXIT_FAILURE);
+ }
+ (void)cookie;
+ (void)operation;
+}
+
+static void get_callback(lcb_t instance, const void *cookie, lcb_error_t error,
+ const lcb_get_resp_t *item)
+{
+ if (error == LCB_SUCCESS) {
+ fprintf(stderr, "GOT \"");
+ fwrite(item->v.v0.key, sizeof(char), item->v.v0.nkey, stderr);
+ fprintf(stderr, "\" CAS: %"PRIu64" FLAGS:0x%x SIZE:%lu\n",
+ item->v.v0.cas, item->v.v0.flags, (unsigned long)item->v.v0.nbytes);
+ fwrite(item->v.v0.bytes, sizeof(char), item->v.v0.nbytes, stderr);
+ fprintf(stderr, "\n");
+ } else {
+ fprintf(stderr, "GET ERROR: %s (0x%x)\n",
+ lcb_strerror(instance, error), error);
+ }
+ (void)cookie;
+}
+
+int main(int argc, char *argv[])
+{
+ lcb_error_t err;
+ lcb_t instance;
+ struct lcb_create_st create_options;
+ struct lcb_create_io_ops_st io_opts;
+
+ io_opts.version = 0;
+ io_opts.v.v0.type = LCB_IO_OPS_DEFAULT;
+ io_opts.v.v0.cookie = NULL;
+
+ memset(&create_options, 0, sizeof(create_options));
+ err = lcb_create_io_ops(&create_options.v.v0.io, &io_opts);
+ if (err != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to create IO instance: %s\n",
+ lcb_strerror(NULL, err));
+ return 1;
+ }
+
+ if (argc > 1) {
+ create_options.v.v0.host = argv[1];
+ }
+ if (argc > 2) {
+ create_options.v.v0.user = argv[2];
+ create_options.v.v0.bucket = argv[2];
+ }
+ if (argc > 3) {
+ create_options.v.v0.passwd = argv[3];
+ }
+ err = lcb_create(&instance, &create_options);
+ if (err != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to create libcouchbase instance: %s\n",
+ lcb_strerror(NULL, err));
+ return 1;
+ }
+ (void)lcb_set_error_callback(instance, error_callback);
+ /* Initiate the connect sequence in libcouchbase */
+ if ((err = lcb_connect(instance)) != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to initiate connect: %s\n",
+ lcb_strerror(NULL, err));
+ lcb_destroy(instance);
+ return 1;
+ }
+ (void)lcb_set_get_callback(instance, get_callback);
+ (void)lcb_set_store_callback(instance, store_callback);
+ /* Run the event loop and wait until we've connected */
+ lcb_wait(instance);
+ {
+ lcb_store_cmd_t cmd;
+ const lcb_store_cmd_t *commands[1];
+
+ commands[0] = &cmd;
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.v.v0.operation = LCB_SET;
+ cmd.v.v0.key = "foo";
+ cmd.v.v0.nkey = 3;
+ cmd.v.v0.bytes = "bar";
+ cmd.v.v0.nbytes = 3;
+ err = lcb_store(instance, NULL, 1, commands);
+ if (err != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to set: %s\n", lcb_strerror(NULL, err));
+ return 1;
+ }
+ }
+ lcb_wait(instance);
+ {
+ lcb_get_cmd_t cmd;
+ const lcb_get_cmd_t *commands[1];
+ commands[0] = &cmd;
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.v.v0.key = "foo";
+ cmd.v.v0.nkey = 3;
+ err = lcb_get(instance, NULL, 1, commands);
+ if (err != LCB_SUCCESS) {
+ fprintf(stderr, "Failed to get: %s\n", lcb_strerror(NULL, err));
+ return 1;
+ }
+ }
+ lcb_wait(instance);
+ lcb_destroy(instance);
+
+ return 0;
+}
+```
+
+
+
+...` ) is no
+longer present.
+
+Once you have a backtrace, send the information (along with the script to
+reproduce, if possible) to your desired support venue.
+
+It is also possible to debug a crash using *Valgrind*, but the process is
+significantly more involved and requires a slightly modified build of Python.
+See the *Contibuting* section for more details.
+
+_`
- * **Unhandled:** `[:unknown-tag :simpara]`
+ Where `` is the name of the class in the SDK (e.g. `Connection` ) and
+ `` is the name of the method (e.g. `` ), thus,
+ `pycbc_Connection_get`
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+ * Code should be portable to Win32
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+ Therefore, only include standard library headers and use `PyOS_*` functions when
+ needed.
```
-**Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
-:simpara]`
+This class method is passed an error code and produces the appropriate exception
+class.
+
+Note that on `get_multi` with the quiet option enabled, you can immediately
+determine if all the keys were fetched successfully or not by examining the
+returned `MultiResult` 's `all_ok` property.
+
+
```
results = client.get_multi(("i exist", "but i don't"), quiet=True)
if not results.all_ok:
@@ -246,8 +403,19 @@ if not results.all_ok:
### Getting Documents by Querying Views
-**Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
-:simpara]` **Unhandled:** `[:unknown-tag :simpara]`
+In addition to fetching documents by keys, you may also employ *Views* to
+retrieve information using secondary indexes. This guide gets you started on how
+to use them from the Python SDK. If you want to learn more about views, see the
+[chapter in the Couchbase Server 2.0
+documentation](http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views.html)
+
+First, create your view definition using the web UI (though you may also do this
+directly from the Python SDK, as will be shown later).
+
+You can then query the view results by calling the `query` method on the
+`Connection` object. Simply pass it the design and view name.
+
+
```
view_results = client.query("beer", "brewery_beers")
for result in view_results:
@@ -256,36 +424,70 @@ for result in view_results:
print "Document ID: %s" % (result.docid,)
```
-**Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
-:simpara]`
+The `query` method returns a `couchbase.views.iterator.View` object which is an
+iterator. You may simply iterate over it to retrieve the results for the query.
+Each object yielded is a `ViewRow` which is a simple object containing the key,
+value, document ID, and optionally the document itself for each of the results
+returned by the view.
+
+In addition to passing the design and view name, the `query` method accepts
+additional keyword arguments which control the behavior of the results returned.
+You may thus use it like so:
+
+
```
results = client.query("beer", "brewery_beers", opt1=value1, opt2=value2, ...)
for result in results:
# do something with result..
```
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]` **Unhandled:** `[:unknown-tag :simpara]`
+Here are some of the available parameters for the `query` method. A full listing
+may be found in the API documentation.
+
+ * `include_docs`
+
+ This boolean parameter indicates whether the corresponding document should be
+ retrieved for each row fetched. If this is true, the `doc` property of the
+ `ViewRow` object yielded by the iterator returned by `query` will contain a
+ `Result` object containing the document for the key.
+
+ * `reduce`
+
+ This boolean parameter indicates whether the server should also pass the results
+ to the view’s `reduce` function. An exception is raised if the view does not
+ have a `reduce` method defined.
+
+ * `limit`
+
+ This numeric parameter indicates the maximum amount of results to fetch from the
+ query. This is handy if your query can produce a lot of results
+
+ * `descending`
+
+ This boolean parameter indicates that the results should be returned in reversed
+ (descending) order.
+
+ * `stale`
+
+ This boolean parameter can be used to control the tradeoff between performance
+ and freshness of data.
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+ * `debug`
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+ This boolean parameter will also fetch low-level debugging information from the
+ view engine.
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+ * `streaming`
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+ This boolean parameter indicates whether the view results should be decoded in a
+ *streaming* manner. When enabled, the iterator will internally fetch chunks of
+ the response as required.
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
+As this is less efficient than fetching all results at once, it is disabled by
+default, but can be very useful if you have a large dataset as it prevents the
+entire view from being buffered in memory.
- * **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
- :simpara]`
-**Unhandled:** `[:unknown-tag :simpara]`
```
results = client.query("beer", "brewery_beers",
include_docs=True, limit=5)
@@ -301,7 +503,11 @@ for result in results:
### Encoding and Serialization
-**Unhandled:** `[:unknown-tag :simpara]`
+The default encoding format for the Python SDK is JSON. This means you can pass
+any valid object which is accepted by the standard `json.dumps` library function
+and you will receive it back when you retrieve it.
+
+
```
# -*- coding: utf-8 -*-
@@ -327,13 +533,29 @@ pprint.pprint(result.value)
print result.value['unicode']
```
-**Unhandled:** `[:unknown-tag :simpara]` **Unhandled:** `[:unknown-tag
-:screen]` **Unhandled:** `[:unknown-tag :simpara]` **Unhandled:**
-`[:unknown-tag :simpara]`` are routing tokens
+which flask passes to the handler as arguments. This means that URLs such as
+`/beers/delete/foobar`, `/foo/delete/whatever` etc. are all routed to here.
+
+When we get an ID, we try to delete it by using the `delete` method. We use a
+`try` block. If successful, we redirect to the welcome page; but if the key does
+not exist, we return with an error message and a `404` status code.
+
+You can now access this page by going to
+`localhost:5000/beers/delete/nonexistent` and get a 404. Or you can delete a
+beer by clicking on one of the `Delete` buttons in the `/beers` page!
+
+` which displays a nice HTML form in which we can use to edit
+it. It passes the template the `Beer` object, a boolean parameter indicating
+that this is *not* a new beer (as the same template is also used for the `Create
+Beer` form), and finally the URL to `POST` to when the form is submitted.
+
+The second is the `POST` handler which validates the input. The post handler
+calls the `normalize_beer_fields` function.
+
+This function converts the form fields into properly formed names for the beer
+document; then it checks to see that the beer has a valid `name`. It then checks
+to see that a `brewery_id` was specified and that it indeed exists. Once these
+checks have passed, it returns a tuple of ( `doc`, `None` ).
+
+The `POST` handler checks to see that the second element of the tuple is false -
+if it isn’t, then it’s an error code, and the first element becomes the error
+message.
+
+Otherwise, the first element becomes the document.
+
+It then sets the document in Couchbase using the `set` method.
+
+The template is rather wordy as we enumerate all the possible fields with a nice
+description :)
+
### templates/beer/edit.html
**Unhandled:** `[:unknown-tag :screen]`
-**Unhandled:** `[:unknown-tag :simpara]` which covers the topic itself more extensively.
+
+In order to use views, you must have already set up *design documents*
+containing one or more view queries you have defined. You can execute these
+queries from the Python SDK and retrieve their results.
+
+You can define views either via the Couchbase Server web interface, or through
+the Python SDK (see
+
+
+ [Couchbase Server 2.1]
+
+
+
+
+ [Couchbase Server 2.0]
+
+
+
+
+ [Couchbase Server 1.8]
+
+
+
+
+ [Couchbase Server 1.8 - Japanese]
+
+
+
+
+ [Membase Server 1.7]
+
+
+
+
+ [Membase Client Library Java]
+
+
+
+
+ [Membase Client Library .Net]
+
+
+
+
+ [Membase Client Library PHP]
+
+
+
+
+ [Membase Client Library Ruby]
+
+
+
+
+ [Membase Client Library Python]
+
+
+
+
View Current Documentation
+
diff --git a/docs_main_new.html b/docs_main_new.html
new file mode 100644
index 00000000..5968d70e
--- /dev/null
+++ b/docs_main_new.html
@@ -0,0 +1,139 @@
+
+
+
+
+
+ [Couchbase Developer]
+
+
+
+
+ [Couchbase Server]
+
+
+
+
+
View All Documentation
diff --git a/layouts/default.erb b/layouts/default.erb
index ccc97dfa..73dd9e04 100644
--- a/layouts/default.erb
+++ b/layouts/default.erb
@@ -59,7 +59,7 @@