Up to this point, the test application has been using the default bucket. This is because it is not authenticated. The default bucket on Couchbase can be useful when you first start out, but as you build more complex applications, you may want to partition your data into different buckets to improve fault tolerance by boosting replication or just so that one bucket can be cleared without affecting all of the data you have cached in other buckets. You may also want to partition your key space among several applications to avoid naming collisions.

Figure 2.1. Figure 1: Creating a private bucket.

Figure 1 shows the dialog in the Couchbase Web Console that demonstrates creating a new bucket called private with two replicas. Here you also choose a password to protect the bucket during SASL authentication. How do you access this bucket? You have already learned about how to make a SASL authenticated connection to Couchbase, if you use the bucket name as the username, and the password you provided when creating the bucket, you will connect to the private bucket for data storage. The following code would accomplish this:

// We have used private as the username and private as the password
// but you would not do this, you would be much smarter and use
// something much harder to guess.
    CouchbaseConnectionFactory cf = new CouchbaseConnectionFactory(baseURIs,
       "private", "private");
     client = new CouchbaseClient((CouchbaseConnectionFactory) cf);