I am happy to announce the first Developer Preview of our official Go SDK (gocb) today.
While in the past, we have had the go-couchbase project which does provide access to many of Couchbase’s features, it was primarily intended to be used internally to our company. gocb marks the first preview of an upcoming release designed and developed specifically to meet the goals of Go developers using Couchbase.
The gocb project is implemented as a set of blocking methods which can be used concurrently from as many goroutines as desired. It is suggested that you distribute your workload across as many goroutines that fit within your application design to maximize the parallelism of the library.
You can find an API reference for the gocb project at: http://godoc.org/github.com/couchbaselabs/gocb/.
Performing Basic Operations
Performing View Queries
Registro em log
While the logging that is available within gocb is still in its infancy, it can provide a great deal of useful information for debugging. Setting up gocbcore to log to the console is quite trivial using a built in logger object. Make sure to only call this once at the beginning of your application though as the logger is assumed to be immutable once any other methods are invoked.
Go SDK Architecture
The gocb library
The gocb library is our developer oriented library intended to provide a simple and easy to use interface to users. This library implements a blocking API which exposes all of our developer oriented functionality to you.
The gocbcore library
The gocbcore library is our internal library which provides all of the network and smart management functionality of the client. This library provides is used by gocb internally.
gocbcore implements a mostly lockless method of dispatching operations, giving your application the ability to easily distribute the load across as many cores as servers in your cluster. This means better performance, and the ability to safely use the client across as many goroutines as you desire without incuring any performance penalty.
Should this use gocb.NewViewQuery ??
vq := gocouchbase.NewViewQuery(\”dev_all\”, \”by-id\”).Limit(4)
rows := bucket.ExecuteViewQuery(vq)
Just another question, is the Golang SDK able to connect to the Sync Gateway?
No. Currently in golang you would connect to SG via it\’s REST API.
There doesn\’t seem to be a Disconnect function. Am I correct in saying that I should only connect once, retain that connection throughout the application\’s lifetime, and that the connection will be released on application-shutdown?
This is correct. While having a Disconnect ability will be helpful for some edge cases, the appropriate way to handle Bucket connections is to create them during application initialization and use the same instance from throughout your application (Bucket methods are safe and performant from as many goroutines as you deem necessary).
Is there a recommended means of shutting down the application to ensure that the underlying Bucket connection is closed, or will it close regardless of the means of shutdown? E.g., system crash, etc.
but what if i will set the bucket connections into a pool with initial and max pool size
and need to close the connections that exceeded the initial size !!.
Why would you be putting the connections in a pool? The gocb library is fully thread-safe and can be safely used from any number of goroutines without any performance issues.
thanks,
but i need the pool to avoid the over-use of server resources,
any way i think closing the connection may be useful to be exported as a method.
Hey, could you elaborate on how pooling the Bucket instances would reduce serve resource usage? In fact, I suspect the result may be the opposite as Bucket connections are rather expensive in terms of the resources used and are highly optimized to perform well across numerous threads.
thanks for reply,
but i mean it will reduce the usage of resources for my server application, not the database server
any way it is a good point to support the closing method
can we use \”bucket.IoRouter().CloseTest()\” method to close the connection correctly ?
This is a test method that was not meant to show up in the repository. It may close the connections properly, but it may also cause your whole application to explode. Please do not use it.
Does this library support pluggable retry strategies and
fail-fast mode?
Hey Paul,
The Go SDK does not support either of these features at the moment. Though if you could explain how you would see those features working, I\’d be happy to consider adding them in the near future.
Cheers, Brett
If an operation that persists data to a node over an open
connection fails in the case of node failure, will the SDK automatically attempt
to establish a connection to the next node that is promoted? Or, should my
application logic instead capture specific connection errors, and respond
accordingly by explicitly attempting to reconnect?
The application attempts to retry storage operations only as long as it is safe to do so. In the case of a node failure once the operation has already been dispatched on the network, the error will be propagated to the user to be handled as the operations true status is unknown at that point and automatically retrying could be problematic.
Thanks. Can you offer an example as regards how to handle such an error?
I notice that if I add a document as follows:
bucket.Upsert(id, &myStruct, 0)
And then invoke a view as per your example, the row variable contains an ID that has no relevance. I\’m not sure where it comes from, but it is not equal to the ID that I set during upsert.
If I reconnect, and then invoke the view again, all works as expected.
I\’ve tried setting a wait period before calling the view, to no avail. I\’m running a single node on a DEV machine.
Actually, I\’m sure that this is due to the fact the the view is not as consistent as other operations. The irrelevant ID seems to be the ID of a previously deleted document.
Hi Brett, does the library support multi-get? Rather than cycle through the results of a view individually, it would be helpful to offer a list of IDs to a single resource to retrieve values in a single call, as per the Java SDK.
Hi Brett,
What\’s the best strategy to adopt when an application needs multiple Bucket connections?
Something wrong with library :(
$ go get gopkg.in/couchbaselabs/gocb.v0
# gopkg.in/couchbaselabs/gocb.v0
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.UnlockCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.TouchCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.RemoveCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.StoreCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.StoreCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.StoreCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.StoreCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCasCallback) to type gocbcore.StoreCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCtrCallback) to type gocbcore.CounterCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… cannot convert cb (type ioCtrCallback) to type gocbcore.CounterCallback
/Users/alec/go/src/gopkg.in/couchbaselabs/gocb.v0… too many errors