I have an application written on java. I need to run two instances of my application on same couchbase bucket. The problem is that the document ids will be same.
I read that Couchbase Server 7.0 supports Scopes. Can I create 2 scopes and then have each instance connect to Couchbase using different scopes? I would not like to create Collections at this point because that will require a lot of change in my application code. Something like this:
– app_instance_1 will connect using Scope_1 and all documents will be in _default Collection of Scope_1.
– app_instance_2 will connect using Scope_2 and all documents will be in _default Collection of Scope_2.
Can I create 2 scopes and then have each instance connect to Couchbase using different scopes?
Yes!
However, I’m pretty sure only the default scope can have a “_default” collection. You can simply name the collection something else, and configure the app instances with both a scope name and collection name.
If I would upgrade to 7.0, existing application can work with it without any change in code because all documents in each bucket will be placed inside _default collection of _default scope of respective buckets.
Now that I will create, lets say, _default2 scope & _default2 collection for app_instance_2, I will need to change the code, is the understanding correct? But will that change be much lesser of a change, possibly just once at the time of establishing the connection?
@pccb You are correct. All documents that existed before upgrading to 7.0 will exist in the bucket:scope:collection path of :_default:_default after the upgrade, and if you do not specify a scope or collection in your code these will default to “_default” so you can access all the pre-7.0 documents without code changes. (Note the default bucket, which existed already before 7.0, is named “default” not “_default”.) A scope is essentially just a namespace layer – a bucket contains scopes, a scope contains collections, and a collection contains documents and indexes (documents and indexes are the leaves of the tree). We use bucket:scope:collection notation by convention but you can think of this as being like a filesystem path, /bucket/scope/collection/, to a folder that contains documents and indexes. Thus, just like in a filesystem, /bucket/scope/collection1/doc1 and /bucket/scope/collection2/doc1 are different documents.
If I would upgrade to 7.0, existing application can work with it without any change in code because all documents in each bucket will be placed inside _default collection of _default scope of respective buckets.
Correct.
Now that I will create, lets say, _default2 scope & _default2 collection for app_instance_2, I will need to change the code, is the understanding correct? But will that change be much lesser of a change, possibly just once at the time of establishing the connection?
If you are already using Couchbase Java SDK version 3.x, then yes, it will be a small change. Instead of this:
Collection c = bucket.defaultCollection();
you would write:
Collection c = bucket.scope("myScope").collection("myCollection");
If you are still using version 2.x of the SDK, you will need to upgrade to 3.x before working with documents in scopes or collections other than the default. See Migrating from SDK2 to SDK3 API.
To be sure, with that one change all my KV operations and N1QL operations will work without any other code change. Is that a correct understanding? for e.g. N1QLs like the one mentioned below can continue to execute from my app:
select attr_1 from <bucket> where __t=‘something’;
and Couchbase will internally execute it against <bucket>:default2_scope:default2_collection.
Ah, I forgot about N1QL. You’ll probably want to run the queries at the scope level instead of the cluster level. One way to do that is to call Scope.query() instead of Cluster.query(). So instead of: