Difference beetween LCB_TYPE_CLUSTER and LCB_TYPE_BUCKET

connections

#1

Hi everyone,

background for my question:

I’m currently working (just started) to create a swift package ( swift couchbase client ) around the c sdk for apple’s opensourced swift language/compiler ( mac/linux (ubunut just now)).

Not used the C SDK direktyl until now ( only the php sdk in php ) i looked into the php extension code how it is done to get a clue about the working and choose a correct implementation way for swift.

The problem is not to get a connection it self, because it is pretty good documentated in the c sdk documentation.

But what got me wondering was, that in the cluser implementation of the php sdk a create options construct will be created like the following: ( not copy pasted from there ):

struct lcb_create_st cropts;
memset(&cropts, 0, sizeof cropts);

cropts.version 		= 3;
cropts.v.v3.connstr 	= "couchbase://localhost/mybucket";
cropts.v.v3.passwd 	= "topsecret";
cropts.v.v3.type    	= LCB_TYPE_CLUSTER

the bucket implementation using LCB_TYPE_BUCKET as cropts.v.v3.type.

So the main question is, what is the different of these two type constant ? Because i didn’t found any reference which calls needs what kind of server handle with a corresponding type, i decieded to ask before i loose several hours of testint to find out the differences between them.

Because of the constant description here ( http://docs.couchbase.com/sdk-api/couchbase-c-client-2.4.4/group__lcb-init.html#ggafb00d9eefaf18691d951141d1ee9b43baeaa2b53de032faf8cf26644019be2b50 ):

LCB_TYPE_BUCKET Handle for data access (default)
LCB_TYPE_CLUSTER Handle for administrative access.

Because of the “Handle for administrative access” i thought to use a dsn/connstr without a bucket name and provide the administrativ user name and password in the struct, but that do not worked. only with bucket and pw ( bucket name and bucket pw ) i could create a connection to the cluster.

Okay, the administrative stuff is done over the http_request stuff/calls, right ? so there should the admin name and pw provided. But why these different types for the normal client handles ?

I’m just very confused for now. So if someone can gibe some simple explentation or just documents to get these things sorted out would be very nice. (I do not need any coding help … just some answers to dig into the right direction and to build a robust swift couchbase client sdk/classes ).

So long

Stefan


#2

I would not recommend using LCB_TYPE_CLUSTER as it is nothing more than a glorified HTTP client. There are some benefits using it though, especially in C, for example not having to deal with another C API or depend on another C HTTP client.

See https://github.com/couchbase/libcouchbase/blob/master/tests/iotests/t_views.cc#L58 for an example of using LCB_TYPE_CLUSTER. In short the CLUSTER type does not connect to a bucket via memcached, and does not parse the vBucket configuration. It merely connects via HTTP and discovers other nodes in the cluster.

I’m curious what happens when you use the administrative username/password, though

Finally, since you are developing a new code (and a new client) bear in mind that the current API will be deprecated in the next release (it will still work fine and I’m not adding compiler warnings just yet). Refer to the “api3” API instead. http://docs.couchbase.com/sdk-api/couchbase-c-client-2.5.5/group__lcb-public-api3.html


#3

Thanky for your reply mnunberg,

that sorted out a lot.

Mabye thinking about directly using the api3 … but it is marked as “experimantal” so i thought to use the old one like in the php extension. Okay, maybe some api3 stuff will change until the next release … but you are right, maybe it is worth to using it and “changing” it on api3 changes instead of rebuild it complete after api3 is working and old one is deprecated/removed.

So far … thank you for your answer.

So long

skyblader aka stefan


#4

API3 will no longer be experimental as of the next release which should be out in a few days


#5

API3 is now stable. You can use it now without worry