We welcome your feedback!

[ewoutp]

This ArangoDB Go driver is still under heavy development, but the concepts behind the API and most of the API functions & types are getting close to what we want them to be.

Note: WE DO NOT GUARANTEE ANY API STABILITY YET.

Before we finalize the API we welcome everyone to to give their feedback on the API. All questions, remarks & suggestions are really appreciated.

To discuss topics, please create an issue in this repo. We'll try to respond as quickly as possible.

[ewoutp]

@diegogub @solher @TobiEiss we hope you all want to give your feedback on this driver as it is right now.

[solher]

Thank you again for contacting us ;)

IMHO, and from what I saw, I don't really have any technical feedback for now. Everything feels modern and I especially appreciate the wrapping based error handling. All (or almost all) the features seem to be implemented which is far from being the case in Arangolite.

I just personally never really enjoyed ORMs (I had a pretty bad experience with active records and never came back to it). In the case of ArangoDB, I'm still not 100% sure that having a library so big with such a big API surface really brings a lot to the user in comparison to what it's going to take to maintain it. I simply wonder if modeling all the ArangoDB concepts/objects as publicly exposed interfaces is really reasonable when the driver is finally only a wrapper around the Go HTTP client.

My very personal opinion is that as a user, I prefer to deal with a lightweight library that gives me efficient and straightforward ways of dealing with usual operations (here running AQL queries) and then giving me the liberty to easily implement custom advanced operations (here basically running HTTP requests against the database), over a more complicated tool allowing me to do everything.

Again, this is my very personal opinion and I'm sure a lot of people have a different vision.

Apart from that and if I'm not mistaking, I didn't see any transaction support. How are you planning to implement it? Are you going to follow the path of JS generation or is a new transaction system incoming?

In any case, thank you for investing time in the development of an official Go driver 👍

[solher]

One last thing about the error handling. Just a quick observation, you would probably not even have to declare a concrete ArangoError implementation if you only used wrappers for error numbers/statuses, for example:

type numberedError struct {
    error
    errorNum int
}

func withErrorNum(err error, errorNum int) error {
    return numberedError{err, errorNum}
}

// HasErrorNum returns true when one of the given error num matches the one returned by the database.
func HasErrorNum(err error, errorNum ...int) bool {
    e, ok := err.(numberedError)
    if !ok {
        return false
    }
    for _, num := range errorNum {
        if e.errorNum == num {
            return true
        }
    }
    return false
}

// IsErrUnique returns true when the error num is a 1210 - ERROR_ARANGO_UNIQUE_CONSTRAINT_VIOLATED.
func IsErrUnique(err error) bool {
    return HasErrorNum(err, 1210)
}

This way, we would not be forced to go back to the error cause when we want to check the value. We just have to assert for a behavior which is more flexible. It is definitely not a game changer or anything but I just wanted to submit the idea.

[ewoutp]

Hi @solher. Thx for your response.

I'll try to give my feedback on the issues you raised.

• API size. In this driver we hope to balance between supporting those API calls that people will frequently use and not being so big that people really lose sight of where they need to go to solve something. Therefore we've made some explicit decision to not expose certain (a lot) API calls.

• Transaction. ArangoDB now supports transactions by means of a javascript function. We're not really sure yet if we want to expose this in this driver. If we do expose it, it will be pretty low level. I mean that you would have to put your javascript code in a Go string and then call some function. We do not have the intention to wrap all javascript stuff in Go functions.

• ArangoError. The only reason this error exists is that most API requests return an error using fields defined in this struct. About the wrapping, this is optional (on purpose). The default implementation of the WithStack & Cause function (variables) is such that there is actually no wrapping at all. However if you want to use it will a library like github.com/pkg/errors, you can and this driver can be configured to use it.

If I missed something or misunderstood things, please let me know.

[ewoutp]

@dalu The ArangoDB server (and the go-driver) support 2 protocols:

1 - HTTP (1.1) with JSON or Velocypack messages 2 - Velocystream (with Velocypack messages), a binary protocol that support multiple concurrent requests on the same connection at the same time.

Velocypack is a compact binary format which has properties similar to json, just binary and a bit smaller.

[prateekj117]

@ewoutp @informalict Is stability guaranteed now? ArangoDB is one of our candidates in considering NoSQL DBs. And this might be a dealbreaker for us. And are all features supported by ArangoDB supported by this driver or not?

[ajanikow]

Hello @prateekj117!

Yes, feature matrix is covered for latest ArangoDB release in v1 driver. This includes data and management operations.

Best Regards, Adam Janikowski.

[prateekj117]

Hey @ajanikow,

Thanks for the info. So it is safe to be used in production? And also have official support from ArangoDB? And also with support from ArangoDB (Or only with paid plans?)?